I rather think this is something which have to be done by the user.

And instead of "global install" people should use packaged applications.

Most of them (drush, phpunit, composer, phpcs, phpcompatinfo... ) being available in the repository, so these should be preferred, and composer installed binaries should not interfere.

"(In reply to Remi Collet from comment #1)
> I rather think this is something which have to be done by the user.
> 

So why I opened this in the first place and why I slightly disagree is because the Composer package overrides the default behavior of storing stuff in ~/.composer and puts it into ~/.config/composer. When I saw that I thought "Ahh nice, so I bet they also registered ~/.config/composer/vendor/bin in $PATH". It (at least for me) suggests a level of (OS-)integration that then turns out to not be there.

> And instead of "global install" people should use packaged applications.
> 
> Most of them (drush, phpunit, composer, phpcs, phpcompatinfo... ) being
> available in the repository, so these should be preferred, and composer
> installed binaries should not interfere.

I guess it's just a personal preference of me to do this with Composer itself. I think its awesome to have the (subsidiary) package managers (Composer, npm, ...) packaged for the OS, but I then like to use those to manage the "actual" packages.

It leads to less problems in case end up wanting to install something (globally) that isn't packaged for Fedora. You could argue that I should go ahead and package it in that case, so I guess this is not really a technical argument but rather one of personal preference / convenience.

In any case, feel free to close this, I don't feel very strongly about this, I just thought it would be a nice convenience / enhancement. (It certainly would be for me ;-).)

Maybe as a compromise we could provide this but comment it out by default, so that there's no change to the default behavior but it's both easier for people to enable and there is a documented best practice way of doing so?

(In reply to tstoeckler from comment #2)
> So why I opened this in the first place and why I slightly disagree is
> because the Composer package overrides the default behavior of storing stuff
> in ~/.composer and puts it into ~/.config/composer. 

What ?

Absolutely no change from upstream

$ composer global require  phpunit/phpunit
Changed current directory to /home/remi/.composer
Using version ^5.6 for phpunit/phpunit
./composer.json has been updated
...

$ ls ~/.composer/vendor/bin/
phpunit

http://pkgs.fedoraproject.org/cgit/rpms/composer.git/commit/?id=58e99ffe35d41a113ac84018f5e1d3d972974111

composer-1.2.2-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-bbcaed7df6

composer-1.2.2-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-bbcaed7df6

composer-1.2.2-2.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-bbcaed7df6

Thanks for the update!

Unfortunately it does not work for me, because on my system Composer is in fact located at ~/.config/composer, so adding ~/.composer/vendor/bin to $PATH does not help.

I tracked this down to Composer itself, see the following in \Composer\Factory::getHomeDir():

        $userDir = self::getUserDir();
        if (is_dir($userDir . '/.composer')) {
            return $userDir . '/.composer';
        }

        if (self::useXdg()) {
            // XDG Base Directory Specifications
            $xdgConfig = getenv('XDG_CONFIG_HOME') ?: $userDir . '/.config';

            return $xdgConfig . '/composer';
        }

\Composer\Factory::useXdg() in turn returns TRUE if there is any key starting with "XDG_" in $_SERVER, of which there are many on my system. So it seems the deciding factor is a pre-existing ~/.composer directory. On a fresh installation this does not exist, so Composer ends up in ~/.config/composer.

I thought whether we could solve this problem by specifying a custom bin-dir to a user-specific location of binaries which are already in $PATH. Unfortunately I didn't see any such directory. I saw ~/bin and ~/.local/bin in .bash_profile but that is apparently not sourced normally.

When I ran

$ composer config --global bin-dir ~/.local/bin

and then sourced .bash_profile manually everything worked as expected after I installed a Composer package globally.

On the other hand, even if we do do that and somehow get ~/.local/bin into $PATH, I suppose it would only be correct to also set the vendor-dir to ~/.local/share which I'm not sure is a good idea...

Another workaround is: mkdir ~/.composer ;)


IMHO, XDG support in composer is (for now) at least partial, at most broken.

The current fix in the RPM is mostly for server (no XDG)

For workstation (XDG), I think this should be fixed in composer.

A bug already exists about the XDG installation layout:
https://github.com/composer/composer/issues/5041

I don't plan to add more change in the package.

composer-1.2.2-2.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.