Bug 1394577 - Global Composer binaries not available
Summary: Global Composer binaries not available
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: composer
Version: 25
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Remi Collet
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-11-13 19:57 UTC by tstoeckler
Modified: 2016-12-02 21:24 UTC (History)
2 users (show)

Fixed In Version: composer-1.2.2-2.fc25
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-12-02 21:24:45 UTC
Type: Bug


Attachments (Terms of Use)
Example script at /etc/profile.d/composer.sh to make global Composer binaries available (110 bytes, text/plain)
2016-11-13 19:57 UTC, tstoeckler
no flags Details

Description tstoeckler 2016-11-13 19:57:55 UTC
Created attachment 1220172 [details]
Example script at /etc/profile.d/composer.sh to make global Composer binaries available

Description of problem:

After installing the composer Fedora package, binaries of globally installed Composer packages are not available in the command line.

I think it would be nice to somehow add the $HOME/.config/composer/vendor/bin directory to the $PATH or, alternatively, but Composer's bin-dir somewhere in $PATH.

This is my first bug report, so sorry if this is not appropriate.

Version-Release number of selected component (if applicable):

Version: 1.2.2
Release:
1.fc25

How reproducible:


Steps to Reproduce:
1. dnf install composer
2. composer global require drush/drush
3. which drush

Actual results:
no drush in (...)

Expected results:
$HOME/.config/composer/vendor/bin/drush

Additional info:

Comment 1 Remi Collet 2016-11-14 13:48:00 UTC
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.

Comment 2 tstoeckler 2016-11-17 07:51:26 UTC
"(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 ;-).)

Comment 3 tstoeckler 2016-11-17 11:24:48 UTC
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?

Comment 4 Remi Collet 2016-11-17 15:57:47 UTC
(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

Comment 6 Fedora Update System 2016-11-17 16:58:56 UTC
composer-1.2.2-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-bbcaed7df6

Comment 7 Fedora Update System 2016-11-17 16:59:01 UTC
composer-1.2.2-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-bbcaed7df6

Comment 8 Fedora Update System 2016-11-18 20:26:40 UTC
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

Comment 9 tstoeckler 2016-11-20 10:52:44 UTC
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...

Comment 10 Remi Collet 2016-11-26 11:43:07 UTC
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.

Comment 11 Fedora Update System 2016-12-02 21:24:45 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.