new composer port request

[p.perroud@…]

composer is a depencies manager that works fine for zend frameworks applications and the like.

On the mac it can be installed as homebrew package.

As a macports user I would like to install it with macports instead.

The composer project is available from here: ​https://getcomposer.org/

[moderndeveloperllc (Mark Garrett)]

+1 from me for this. The only question I would have is how macports handles self-updating apps like this especially as it's still technically in alpha (for the past two years). Perhaps install the latest "official" build with displayed instructions to optionally run composer selfupdate?

[moderndeveloperllc (Mark Garrett)]

Cc Me!

[info@…]

I realize there may be benefits to running it through MacPorts, but for folks who want a quick install without Homebrew, this worked for me to install Composer in the MacPorts /opt/local/bin directory:

$ curl -sS https://getcomposer.org/installer | sudo php -- --install-dir=/opt/local/bin
$ sudo ln -s composer.phar /opt/local/bin/composer

[ryandesign (Ryan Carsten Schmidt)]

Duplicate #55580 mentions that ports for composer have been developed at ​​https://github.com/sjorek/MacPorts-PHP. I have not evaluated them.

[brandung-sjorek (Stephan Jorek)]

@ryandesign I'm the developer of ​https://github.com/sjorek/MacPorts-PHP

In this comment ​https://github.com/sjorek/macports-php/issues/2#issuecomment-1544344271 I collected my (selfish) arguments, why I'm still struggling with the idea of submitting this port-definitions to the MacPorts-base. To save you some time, I'll quote them here:

… one must consider the tight integration of my composer-ports with the historically evolved ​bash-completion (variant), which in turn is provided ​as separate port here and implemented in ​https://github.com/sjorek/composer-bash-completion.

The difficulty I see (at least for me) is that I don't want to loose the features of this bash-completion implementation. I'm aware of the “new” builtin (symfony-driven) bash-completion support in composer itself: ​https://getcomposer.org/doc/03-cli.md#bash-completions And I invested some time to ​enhance parts of the new bash completion, but still the new bash-completion lacks features from my implementation (which I really use a lot). To make it short - a shift of the (plain) composer-port to the macports-base would be much easier (for me), if composer's builtin bash-completion would be a little bit more sophisticated, because then I could get rid of my implementation, and I would only have to transfer the plain composer-Ports to macports and use its builtin bash-completion only.

See how selfish I am? 😄

This bothers me since quite a lot of time (years) and has nothing to do with my will to contribute (and even maintain) the composer port-definition.

[ryandesign (Ryan Carsten Schmidt)]

Replying to moderndeveloperllc:

The only question I would have is how macports handles self-updating apps like this

Any self-updating functionality must be disabled in ports. MacPorts is the way ports are updated. Files installed by ports should not attempt to replace themselves with newer versions.

A PR for composer was submitted here: ​https://github.com/macports/macports-ports/pull/19471

[sjorek (Stephan Jorek)]

Replying to ryandesign:

Replying to moderndeveloperllc:

The only question I would have is how macports handles self-updating apps like this

Any self-updating functionality must be disabled in ports. MacPorts is the way ports are updated. Files installed by ports should not attempt to replace themselves with newer versions.

A PR for composer was submitted here: ​https://github.com/macports/macports-ports/pull/19471

Just for the record: I have created a follow up regarding this policy: ​https://github.com/macports/macports-ports/pull/19471#issuecomment-1948977342