Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Install command #25

Closed
eproxus opened this Issue · 23 comments

4 participants

@eproxus

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.

@yrashk
Owner

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.

@yrashk
Owner

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.

@jlouis

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).

@eproxus

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:

  • A amateur user "just wants to use a library" without caring for a "correct" or "beautiful" path structure.
  • A proffesional developer wants everything on the path while developing, and knows that when a production system is released, she have to include all the apps is the "right" way anyway (by using fetch or copying the libraries etc).
  • A production system is being set up and the way to reference all the libraries is by installing everything with agner and then "just starting the node". (This of course doesn't follow the OTP release standards, but agner doesn't help with that anyway right now).
@yrashk
Owner

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 -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?

@yrashk
Owner

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)

@yrashk
Owner

Quick update: --compile/-c has been renamed to --build/-b for naming consistency reasons

@eproxus

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.

@yrashk
Owner

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.

@eproxus

Well, with that logic fetch is not needed either, one could just download by using agner | wget | tar | ... etc.

@yrashk
Owner

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

@eproxus

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.

@yrashk
Owner

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.

@eproxus

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.

@yrashk
Owner

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?

@eproxus

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.

@nox

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"].

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"].

@yrashk
Owner

makes sense

@yrashk
Owner

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.

@nox

Double copying? Having a custom install_command doesn't prevent default install?

@yrashk
Owner

It does not. Default install happens unconditionally.

@nox

Isn't that bad?

@yrashk
Owner

I don't know, I initially decided that it's not bad. We can change this if we'll have compelling arguments.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.