It would be nice with a agner install command that fetches packages into some configured folder (user, or maybe system wide, or both), compiles them and adds a path in the .erlang file so the libraries are available in all shells.
While this is not an original intended use (I myself never share libraries across projects, each project has its own set of dependencies), I do realize that some people might still want this.
At this moment we only have fetch command which will get the package downloaded to a directory of your choice (it will not add it to .erlang).
Also agner itself doesn't have any compilation mechanisms (at least to date) as it heavily relies on its own friendly relationship with rebar :)
That said, I am not saying we're not going to implement it. I just want to get a better picture of how we can fit this into our vision so all things are nice & consistent.
I've currently added two options for the fetch command. Now you can either simply fetch & compile:
agner fetch --compile misultin
or fetch, compile & add to .erlang:
agner fetch --compile --add-path misultin
Note that currently it only builds rebar-compatible packages, but that's to be fixed soon.
Hopefully that covers your case. Please let me know if you have any thoughts.
An alternative way is to add it into the $ERL_LIBS environment variable, which you can read with os:env/1 I believe (it is in the os module).
I think my idea was to use that feature in a development tool/environment, so if I would produce a production system or a release I would use the normal fetch. The feature here is not that the code is compiled (although that is required if it should magically appear on your Erlang code path), but that the code is available "everywhere" after a simple install command (much like gems or homebrew etc).
I do understand that the code is not compiled when using fetch and that's how it should be. I see fetch as something you would use when creating a system or repository "a bit more officially", and install as something that would put the library/program on your path and let you use it everywhere, e.g. for happy hacking.
Some uses could be imagined:
My understanding is that the scenarios described above are covered with fetch. If you want to put it into some global directory, just do fetch package /path/to/put/it/to.
fetch package /path/to/put/it/to
fetch -a will append your .erlang to let you have your library magically available everywhere.
Please let me know if I am still missing something, which scenario is not covered?
Also, speaking about compilation, agner can compile non-rebar compatible packages, provided they have a build_command property (for example, yaws: https://gist.github.com/bf2fad0709e8c70cf9eb)
Quick update: --compile/-c has been renamed to --build/-b for naming consistency reasons
Yes, you are right in that it is covered by the fetch -b <package> /path/to/put/it/to. For me it's a convenience thing, so I like to have such simple commands that let me do things quickly without having to remember paths or with the chance of typing something wrong.
fetch -b <package> /path/to/put/it/to
Another update: there is actually an install command now, but it will only work for packages that have an explicit install_command property.
Speaking of installing arbitrary packages, I would simply recommend writing a simple shell alias or script that will just invoke agner build package /standard/path/package or something. Should be very trivial.
agner build package /standard/path/package
Well, with that logic fetch is not needed either, one could just download by using agner | wget | tar | ... etc.
agner | wget | tar | ...
Well, frankly, this is an overly exaggerated statement. fetch does have a lot of somewhat complicated logic, while this is a matter of deciding where to install the whole package — done once and fairly trivially — and this seems to be a reasonable approach as I don't see a common standard on what people mean by "installing packages".
And again, packages that have install_command in their spec are installable with agner install
Yeah, I see what you're saying.
The downside with using the packages own install command is that the location of installed Erlang packages will wildly differ.
The thing is that install_command is provided with AGNER_INSTALL_PREFIX OS env variable that is highly recommended to be used as a destination for the installation (that's what all installable packages use to date), so they are actually all collected in one place.
Ok, that's kind of what I'm looking for.
So what we're speaking about is if agner should provide a "default" install based on rebar in case a package doesn't have install_command specified.
I think that might actually be reasonable and fairly trivial to implement. What I can do is if install_command is not available, just copy the entire content of the build directory and be done with it. Sounds good?
Yeah, I would mainly use it during development so I'd appreciate that the source and all build artifacts were still there. That means that I could go in and "hack" a library, recompile and directly use it.
The default install command should introduce a new package property install_dirs to specify the directories to install. Its default value should be otp as an alias for ["doc", "ebin", "include", "priv"].
["doc", "ebin", "include", "priv"]
If the value is otp, agner should fail only if there is no ebin directory, otherwise it should fail on any missing directory.
We could also support otp as a valid item for install_dirs for easy appending, e.g. [otp, "templates"].
Default installation method is done as of 3d8fc24
@nox you might want to remove your "standard" install_command you used in your packages just to avoid double copying. Nothing crucial, it should still work, but it will cause less confusion.
Double copying? Having a custom install_command doesn't prevent default install?
It does not. Default install happens unconditionally.
Isn't that bad?
I don't know, I initially decided that it's not bad. We can change this if we'll have compelling arguments.