Require new packages

[bobmulder]

Hey guys,

I've been talking at the composer repository about creating some stuff to work with composer in your browser.

I've started a repo to work on it: https://github.com/bobmulder/composer-ui

But, I was hoping this already existed. I've found this repo, and it goes to the direction I am working on. So my question, are you interested in expanding this, or don't you agree with this strategy?

Also you are welcome to contribute at my repo (when there's more structure ;P)

Greetz

Bob

[thomasjthomasj]

Hi Bob

Great to hear from you! What you are doing is actually along the lines
of what we eventually wanted to do with Up, although there are certainly
stability concerns as it gives a lot of power to third party developers
to mess up your application in a live environment. I'd recommend
checking out the Reddit thread discussion when we launched it -
https://www.reddit.com/r/PHP/comments/33ge3s/introducing_up_a_library_for_selfupdating_web/

That said, I definitely think there's a use case for it as long as
people are aware of the risks so I'm interested in your project. Not to
promote our own stuff too much, but I would recommend using Up as it
looks like in your repo currently you are relying on developers having a
'composer' command on their server, where they may not have Composer
installed globally and be calling 'php composer.phar'. There is the
downside that ironically Composer doesn't use version control so we had
to use our own fork, which is naturally a bit behind Composer's own updates.

Anyway, I hope this all makes sense, I'll be sure to keep an eye on your
repo :)

Thanks,
Thomas

On 22/09/2015 09:57, Bob Mulder wrote:

Hey guys,

I've been talking at the composer repository about creating some stuff
to work with composer in your browser.

I've started a repo to work on it:
https://github.com/bobmulder/composer-ui

But, I was hoping this already existed. I've found this repo, and it
goes to the direction I am working on. So my question, are you
interested in expanding this, or don't you agree with this strategy?

Also you are welcome to contribute at my repo (when there's more
structure ;P)

Greetz

Bob

—
Reply to this email directly or view it on GitHub
#9.

Thomas Marchant
Lead Developer

[bobmulder]

Hi @thomasjthomasj,

Thanks for your reply! I've watched your code and like the approach of calling composer.
See this issue I started at composer composer/composer#4429. The guy there adviced me to use commands (via symfony/process), but your approach seems nice too...
What's your motivation behind this?

And how to continue? I would like to extend up, else I would rip some code from it and build my own... Maybe are you interested to join? Feel free to get in touch via https://gitter.im/bobmulder. ;)

[thomasjthomasj]

Hi @bobmulder

This was motivated by our desire to make our platform, Mothership, as easy to install as possible. Explaining to people who perhaps don't have much experience with PHP or are used to working with platforms like WordPress how to install the platform would often elicit scared faces at the mention of having to install Composer, so we built Up to make Composer invisible and automatic. Of course, you currently still need Composer to update Mothership installations, but at some point we will make it possible to update Mothership without needing a local installation of Composer. This would probably still done in the command line rather than via a UI as we wouldn't want users to update via Composer in the live environment

If you want to expand or contribute to Up, feel free! Details of the license can be found here. We definitely welcome pull requests! The main thing I would say about contributing is maintaining the simplicity of the public API, i.e. methods should be consistent with the commands in Composer as well as the methods that already exist within Up.

Thomas

[kuiche]

@bobmulder @thomasjthomasj kinda said this, but we chose to go this route (requiring composer as a dependency) so that users don't need composer installed globally (or need to pass a composer path to the lib) to make it work. The composer installation documentation doesn't even tell you how to install it globally, so it's quite likely that users will just have composer.phar as a file somewhere. Up should just work without having to worry about linking the app up to a composer installation.

A good example of where this works out quite well is in the mothership installer. As it's distributed as a pre-built .phar, you don't need composer to be installed. It just works.

Another problem with running composer externally (not sure if Symfony processes manage this, they very may well) is that *nix terminal have big differences to windows etc. which makes testing integrations based on running cli commands a bit awkward. If requiring like Up, you don't need to worry about that.

A big problem with Up's method is that the composer repo's versioning sucks. It maintains other repositories versions very well, but the composer/composer repo itself is pretty badly semantically versioned. The last tag created was 1.0.0-alpha, that was in april 14. The only ways to fix this is to do what we did: fork composer and maintain your own versions - this sucks as you have to keep it up to date or bug the composer devs to impose versioning.