Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Install command #25

Closed
eproxus opened this Issue Jan 28, 2011 · 23 comments

Comments

Projects
None yet
4 participants

eproxus commented Jan 28, 2011

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.

Owner

yrashk commented Jan 28, 2011

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.

Owner

yrashk commented Jan 28, 2011

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.

Contributor

jlouis commented Jan 28, 2011

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 commented Jan 28, 2011

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

yrashk commented Jan 28, 2011

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?

Owner

yrashk commented Jan 28, 2011

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)

Owner

yrashk commented Jan 28, 2011

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

eproxus commented Jan 30, 2011

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.

Owner

yrashk commented Jan 31, 2011

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 commented Feb 1, 2011

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

Owner

yrashk commented Feb 1, 2011

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 commented Feb 1, 2011

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.

Owner

yrashk commented Feb 1, 2011

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 commented Feb 1, 2011

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.

Owner

yrashk commented Feb 1, 2011

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 commented Feb 2, 2011

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.

Contributor

nox commented Feb 10, 2011

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

Owner

yrashk commented Feb 11, 2011

makes sense

Owner

yrashk commented Feb 22, 2011

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.

Contributor

nox commented Feb 22, 2011

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

Owner

yrashk commented Feb 22, 2011

It does not. Default install happens unconditionally.

Contributor

nox commented Feb 22, 2011

Isn't that bad?

Owner

yrashk commented Feb 22, 2011

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