composer stores vendor dir in `$XDG_CONFIG_HOME`

[ghost]

I seem to have a vendor directory with all source files in $XDG_CONFIG_HOME when they should be stored in $XDG_DATA_HOME. With the XDG specification I would expect to see in:

~/.config/composer/
   composer.json
   (maybe composer.lock)

~/.local/share/composer/
     vendor/
        somepackagedir/

or all of the above in ~/.local/share/composer

I do have all 3 of XDG_CONFIG_HOME, XDG_DATA_HOME, and XDG_CACHE_HOME set.

I'm using

$ composer --version
Composer version 1.0-dev (8bf46768f3f5397c259b77321b2e887a53624adb) 2016-03-10 16:31:09

[Seldaek]

So this is.. only for composer global require ... stuff right? I doubt we can or want to change that really, as it'd mean the default for vendor-dir would have to change depending on a bunch of variables, and also it's not exactly BC :/

You can easily do it yourself by setting the vendor-dir in ~/.config/composer/composer.json though to point to where you want.

[ghost]

then the only real fix is to ignore $XDG_CONFIG_HOME and just drop it all in $XDG_DATA_HOME. and it sounds like that's improbable. ATM though, this is just totally non-compliant with the spec.

[Seldaek]

It's not impossible to fix I suppose, but it might break people's setup as they might have XDG_DATA_HOME/composer/vendor/bin in their PATH and stuff like that. Unfortunate but not sure if worth fixing.. Or maybe just fix it for new setups? But that can lead to confusion as well.

[ghost]

you mean $XDG_CONFIG_HOME/composer/vendor/bin ? because what you said is the way it should be (and not the way it is now).

[ghost]

oh, to clarify, when i said everything under ~/.local/share/composer, I wasn't suggesting to change the directory structure underneath.

[Seldaek]

Yeah I mixed up the name sorry, but anyway you see my point? Right now global composer installs are mainly used for global utilities, so they're in PATH, if we suddenly move it we break stuff.

[ghost]

yeah, I know it will break stuff. I just wonder for how many, and how this issue went uncovered? I should have been more active in testing this PR, i just thought my feedback had been taken into consideration and that https://github.com/composer/composer/pull/1407#issuecomment-123712287 was the mark of that.

For me, having this PR is actually a worse situation out of the box, than it was before.

[alcohol]

I personally think the whole global flag/command is a painful source of confusion either way. I understand it has its use-cases, but in general I think most people have different expectations from it. If anything, it deserves a good refactoring with clear documentation, or just a straight-up removal (cause there are other ways to achieve the same goal).

[Seldaek]

@alcohol we know you don't like it, no need to repeat it on every issue related to it :) It's there and IMO it's convenient and useful and there to stay. Not sure what you think is unclear about it? It just needs a PATH entry and then composer global require/update lets you install global utils. Sure you can do it without global by using -d ~/composer instead of global but it doesn't hurt to have, and it's pretty much all it does.

@jrobeson your feedback was taken into account for rollback files AFAIK, but nobody mentioned the vendor dir issue, and I didn't think of it. I think it can be fixed for new setups without doing much breakage, then people can migrate their setup themselves if they care and it'll start using the correct path then.

[alcohol]

@seldaek quite a lot of people who are new to composer quickly/often relate it to npm's global. Which is quite different..

[Seldaek]

How is it so different? At least I use both for the same.

From NPM docs:

If you want to use it as a command line tool, something like the grunt CLI, then you want to install it globally. On the other hand, if you want to depend on the package from your own module using something like Node's require, then you want to install locally.

[alcohol]

A global install on npm also means you could use it locally though, doesn't it?

[Seldaek]

Maybe you could but it sounds like a terrible idea and I have never seen anyone rely on that.

[ghost]

@Seldaek : so we want to just put everything in $XDG_DATA_HOME ? I don't think we can actually comply to the spec fully, since we can't put composer.lock where it should go either.

[stof]

A global install on npm also means you could use it locally though, doesn't it?

@alcohol not by default. You need an additional env variable to tell Node to look for modules in the global config

@Seldaek IMO, the most confusing part of composer global is that it installs all global utilities as dependencies of the same global project, which means that it requires all utilities to have compatible deps and it won't use locked dependencies of these tools (meaning things might break, for instance when Satis is not yet updated for a recent change in composer as its lock file still uses the older version)

[barryvdh]

Agreed, it would be easy to install magerun/drush/laravel installer etc with composer global install .., but when you have > 1 project, it's not really easy anymore..

[jcrben]

Definitely don't think everything should be tossed in the data directory.

Agreed with this comment:

I think it can be fixed for new setups without doing much breakage, 
then people can migrate their setup themselves if they care and
it'll start using the correct path then.

In the meantime having some files in an improper folder isn't the end of the world. Updating the source code doesn't need to remove those files, but users would have to update their PATH going forward.

[remicollet]

Another point about XDG installation layout

For now, scripts are installed in vendor/bin Wouldn't it make sense to have them in ~/.local/bin instead.

The huge benefit is that directory is (usually) in the user PATH.

Again, workaround exists (setting bin-dir or setting PATH), but I think it could be cleaner.

[imme-emosol]

So for the time being this might make composer most conforming to XDG standards ?:

composer global config bin-dir "${XDG_BIN_HOME:-${HOME?}/.local/bin}"
composer global config vendor-dir "${XDG_DATA_HOME:-${HOME?}/.local/share}/composer"

---

Got XDG_BIN_HOME from : https://www.freedesktop.org/software/systemd/man/latest/file-hierarchy.html#~/.local/bin/ . Its not rolled out everywhere, it seems : https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/14 .

The composer packaged with fedora's has the Composer\\Factory::useXDG disabled ( https://src.fedoraproject.org/rpms/composer/blob/rawhide/f/composer-noxdg.patch ).

Adding composer its vendor-bin-dir to PATH ( as mentioned in for instance https://github.com/composer/composer/issues/11439 ) seems to be somewhat contradicting to the idea of standardizing/minimizing desktop paths .

Doing export COMPOSER_BIN_DIR="${XDG_BIN_HOME:-${HOME?}/.local/bin}" would cause issues (for example https://github.com/composer/composer/issues/6700) with projects outside ${XDG_CONFIG_HOME:-${HOME?}/.config}/composer/ .

Adding a .env ( that has COMPOSER_BIN_DIR ) in the home-dir ( to be parsed by some shell-extension ) seems like too much hackery ( and is less likely to be parsed/used when doing composer global .. from some other path ) .