Subdirs

[willghatch]

This pull request I expect to be more controversial than my configuration one.

This patch allows for bundles to target subdirectories of the cloned repository, or files directly. I believe this is a good and important feature, as it will allow users to target plugins with non-standard structure or naming. From reading your conversations with the author of Antigen, I take it that you feel strongly about enforcing a standard (.plugin.zsh), but not all developers will follow that. I think forcing users to fork every non-standard repository they want to use is a little extreme, and allowing users to specify a subdirectory or file within the main repository will give the freedom to use these plugins without having to maintain forks.

My haskell experience is... limited. I haven't used it for some time, and I never used it much in general, so I just did my best to make the smallest changes to make this work. I'll understand if you find problems with the code itself, and if you do I would appreciate any suggestions you may have.

If you disagree with this patch's functionality, I'll understand, but just like you more speed and simplicity than antigen offered... I need the speed and simplicity with some flexibility. But I'm not keen on maintaining a fork, especially in a language I'm not proficient in (though I mean to learn it well when I have more time for that), so if you are willing to bend on this philisophical point, I would love to get this functionality in.

[Tarrasch]

Thanks for keeping the two PRs seperate. I hope you enjoyed coding some Haskell. If I merge this I'll probably rewrite parts of it to make it more Haskellish. I'll be happy to do that. But I first want to discuss the idea itself of not forcing a convention.

I think forcing users to fork every non-standard repository they want to use is a little extreme, and allowing users to specify a subdirectory or file within the main repository will give the freedom to use these plugins without having to maintain forks.

Do you find it extreme really? I don't find it extreme since it is easy to do and has many other benefits. It's simple to click the fork button and rename a file from the github web browser interface. In addition, you get "version pinning" for free, I hate it when my production machine suddenly fails because of somebody pushing something broken to master (I don't use arch :)), but I digress.

But I really don't want to reject a PR if it's a requested feature. I'll maybe add patches on top of your work and then you can also learn how you would do it the proper Haskell way. Then your code contributions will be merged in as well. :)

Does this sound OK?

[willghatch]

I'm good with whatever gets the functionality in, because I want to use it. Whether any of my code is included doesn't matter much to me. I did think that configuration thing was unhaskellish... but it didn't break the current interface, so I went with it. What do you think would be better? I'm not attached to the way I did any of this, it was just the first way I got it to work. I guess I wanted the functionality so I could start using it, but in general I wanted to put the idea out there, because it will make it a much more flexible tool.

As far as the forking thing... I find it at least quite annoying. I generally like to be using the latest software, at least for things UI related. So of course I do use Arch (which you may have guessed from my serendipitously Arch-like auto-generated profile image that I like enough that I haven't bothered changing it), and on other systems I'm always frustrated by having older versions. At work I have to use Scientific Linux 6.5, so invariably I have the better part of a Linux distribution built from source in my home directory because I want to use newer stuff. When I wanted to use Xmonad I had to bootstrap GHC by building a bunch of intermediate versions starting from one that was like 8 years old. Knowing myself, if I forked stuff I would end up going through and checking them every so often to pull and sync up my forks with the main line, maintaining my changes on top of them... and that doesn't appeal to me. I know I'm not the only one that would do this. And I also know people who would probably forgo using a plugin rather than fork it, even if it is easy.

At any rate, if you want to build this functionality that would be great, or if we can find a configuration format for it that you find acceptable, I'm happy to write a better version of this patch after brushing up on my Haskell. Though that likely wouldn't be until... maybe January.

At any rate, I've rambled too much. Thanks for merging the other patch, and responding so quickly.

[Tarrasch]

Cool! I think I'll just implement this feature myself, and you can study the patch for how a more Haskellish interface could look like. :)

I'll hope to do this soon since it's so small (even though my non-github life is a bit hectic now :)).

Just one question. How would you like to see this functionality work? Currently. It wants to find one and only one *.plugin.zsh. How would the user specify what to source instead? Should the user specify a list of files you should source on? How does the fpaths work?

Here's some imaginatary syntax to get us thinking.

bundle "Tarrasch/zsh-functional" ["file-to-source.zsh", "another-file-to-source.zsh"]

Alternanatively, instead of the user specifying a list, we can copy the behavior of zsh-users/antigen. They are specified in the antigen docs.

[Tarrasch]

(By the way, I'm super excited to see people actually using this and caring about it :))

[willghatch]

I think a list like that is a fine way to do it. If it is empty you can default to using / as the subpath, like antigen does, and then if it is a directory, just grab the plugin.zsh, or if it is a file, source it. As long as you can specify a full path to a file, I don't think it's necessary to have all the special cases like antigen has of loading init.zsh, .zsh, or .sh. As for the fpaths... perhaps just add the path given if it's a directory, or if a file is given, the directory it's in (a simple dirname $file type thing). That's pretty close to how antigen does it. I guess the closest thing to antigen would be to have two strings, but a list as the second argument gives more flexibility.

I'm pretty happy you made this, because my zsh start times with antigen were between 1.5 to 3 seconds on the computers I use most, but with antigen-hs they're both less than 1 second.

[Tarrasch]

See #13, where I did a more Haskellish implementation.