Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

composer vendor/bin not set in $PATH and owner issue. #210

Open
strausmann opened this issue Mar 6, 2022 · 4 comments
Open

composer vendor/bin not set in $PATH and owner issue. #210

strausmann opened this issue Mar 6, 2022 · 4 comments
Assignees
Labels
bug Something isn't working

Comments

@strausmann
Copy link
Contributor

strausmann commented Mar 6, 2022

Describe the bug

Setting the BIN directories of the composer vendor directory are not set correctly when starting the workspace.
Normally this should be set via this command.

# Add Workspace/Project composer bin folder to $PATH
export PATH="$PATH:$HOME/.config/composer/vendor/bin:$GITPOD_REPO_ROOT/vendor/bin"

In addition, the Composer Global folder belongs to the owner "root:root" and not "gitpod:gitpod".

Screenshots

image

image

Steps to reproduce

  1. start workspace
  2. check the $PATH variable.
    echo $PATH | grep vendor

Expected behavior

  • System-wide use of the programs in the "vendor/bin" folders of the Global and User composer directory.
  • Running composer global require without sudo

Additional information

@strausmann strausmann added the bug Something isn't working label Mar 6, 2022
strausmann added a commit to strausmann/gitpod-laravel-starter that referenced this issue Mar 6, 2022
strausmann added a commit to strausmann/gitpod-laravel-starter that referenced this issue Mar 6, 2022
strausmann added a commit to strausmann/gitpod-laravel-starter that referenced this issue Mar 6, 2022
strausmann added a commit to strausmann/gitpod-laravel-starter that referenced this issue Mar 6, 2022
@apolopena
Copy link
Owner

@strausmann
Lets talk this through because I am not fully understanding the use case for calling composer from the vendor/bin folder when its already installed in /usr/bin. Does this article sum up the use case?
https://www.chriskankiewicz.com/post/run-composer-binaries-from-project-directories

  • By Gitpod design ownership of the binaries in /usr/bin/ are always root. Check it out by running ls -al /usr/bin/
  • I have not seen a situation where sudo is required to run a composer command, all the other binaries in /usr/bin behave the same way.
  • For context I wanted to find the issue where we added
    # Add Workspace/Project composer bin folder to $PATH
    export PATH="$PATH:$HOME/.config/composer/vendor/bin:$GITPOD_REPO_ROOT/vendor/bin"
    Do you know which issue that was?
  • Do you think this issue is caused by the above line of code not firing off or ending with a silent error?
  • Can you show me a use case where calling composer with sudo is required?
  • What is your use case for using composer from vender/bin rather than /usr/bin?

@apolopena apolopena added this to the v1.6 release 🚀 milestone Mar 6, 2022
@strausmann
Copy link
Contributor Author

@apolopena

this is not about running composer from the vendor/bin directory.

Since I'm using GitLab, I can't use the GitHub changelogger which is already integrated in this project.

As an alternative I use this project here.

https://github.com/churchtools/changelogger

For the installation I often use the installation into the Global Composer directory and not into the composer directory of the project itself.

composer global require churchtools/changelogger

So that the command "changelogger" works then, the vendor/bin directories must be deposited in $PATH.

@strausmann
Copy link
Contributor Author

# Add Workspace/Project composer bin folder to $PATH
export PATH="$PATH:$HOME/.config/composer/vendor/bin:$GITPOD_REPO_ROOT/vendor/bin"

If you execute this line after the project has been completely loaded in the workspace, everything works as well. The vendir/bin paths can be found in the $PATH.

I don't understand why it doesn't work in the init-complete.sh or before-tasks.sh though....

@apolopena
Copy link
Owner

I get it now. I feel like this is a regression. It could be some wierdness with Gitpod prebuilds and the init task. I'll look into it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants