Requiring Composer in 4.0

[Christopher Pitt]

Here's another good reason to require Composer for 4.0: https://github.com/silverstripe/silverstripe-framework/pull/4172

[Michael Strong]

Yes please!!

On 8 May 2015 at 20:26, Christopher Pitt <cgp...@gmail.com> wrote:

Here's another good reason to require Composer for 4.0: https://github.com/silverstripe/silverstripe-framework/pull/4172

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

--

Michael Strong | Platform Support Developer
SilverStripe
http://silverstripe.com/

Phone: +64 4 978 7330
Skype: micmania1

[Loz Calver]

This gets another +1 from me.

In my opinion, the only real decision to be made here is this: do we still provide a precompiled vendor/ directory in the ZIP download? Or perhaps that should be do we continue to provide a ZIP download at all? I think, at least for the foreseeable future, we should provide a ZIP containing vendor/autoload.php etc for the few(?) who don’t use composer as it gives us the best of both worlds:

• Allows PRs like the one linked above to be merged
• Allows us to move stuff out of thirdparty/ and use composer to grab it/autoload it (I’m looking at you, Flysystem/asset abstraction RFC ;)). Added advantage of faster autoloading
• Keeps the entry-barrier low, still no CLI required

As far as I can see, the only potential downsides to this approach are:

• Adds an extra step to the release process? It looks like we’re already bundling vendor/, so perhaps not - I just wasn’t aware that we were doing that!
• Possibly tricky to communicate that you must use composer or download the ZIP from ss.org - downloading/cloning from Github isn’t enough on its own. I don’t imagine many people would be caught out by this, though: you still need to setup an .htaccess or provide an index.php, so just downloading an archive from Github has never “just worked”
• We would need to remind ZIP users to upload vendor/ to their servers or their sites won’t work
• If we start moving dependencies to composer from thirdparty/, do we set specific version constraints or rely on ~/^ operators? If we use semver-like operators to set constraints, do we need to be able to communicate to SS devs if/when a dependency has a security fix, however unlikely?
• ZIP archive users will have to wait until the next SS release for a new feature/bug fix, but I guess that’s unavoidable - it’s just another reason to learn composer!

Loz

[Ingo Schommer]

I think all the potential downsides which Loz has listed are minor to non-existent issues, outweighed by the advantages - so +1 from me.

One downside that hasn't been mentioned though: A "composer create-project" and "composer install" will be even slower than it already is.

Third parties will be pinned to stable versions, so most devs will install them from a Github ZIP download (fast) rather than Git clone (slow).

I'd want to see some benchmarks (uncached on a standard network connection) before making a decision for core.

[Anselm Christophersen]

This gets a big +1 from me, just one note: I had my brother over this weekend who’s had an ecommerce site running on SilverStripe for many years, and has always done things himself, was a pretty steep learning curve when I had to explain him how to get ss-shop.org up and running on a test server ;) So it might be good to at least cater for this kind of users.

[Loz Calver]

R.e. composer performance: I usually specify the --prefer-dist option, perhaps that’d be a good suggestion on our install page? Laravel suggests the same thing when using create-project. I’ve just tested this (~20mbit connection):

With cache:

time composer create-project silverstripe/installer test 3.1.12   -   real 0m28.306s
time composer create-project --prefer-dist silverstripe/installer test 3.1.12   -   real 0m15.465s

Wiping composer cache each time:

time composer create-project silverstripe/installer test 3.1.12   -   real 1m15.603s
time composer create-project --prefer-dist silverstripe/installer test 3.1.12   -   real 0m49.769s

Loz

[Michael Strong]

Lumen have a nice solution to composer create-project taking a lot of time. They have a nice little installer which is a lot faster and very easy to get setup. I haven't looked into how it works yet though. Docs here: http://lumen.laravel.com/docs/installation#install-lumen

The other benefit of requiring composer is that we can rely on its autoloading at some point in the future as soon as we get our own house in order. The destruction of the class manifest is near, I can almost taste it.

--

You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

[Sam Minnée]

Why not have our cake and eat it too?

Our .zip / .tar.gz downloads should be built from a composer create-project call, and include composer.phar in their root directory. That way, if someone had downloaded the zip file, they can still run "php composer.phar require my/modules".

It would be an extra 1mb in the download, but I think the extra download size is justified, as pretty much everyone will need composer, and if they already have it installed then they can use composer create-project instead.

Until we move our codebase out of the default webroot (another good idea for 4.0) we'd have to think through the security implication of having the extra file in the webroot. Another .htaccess rule is a simple solution, and if that's missed, it appears that .phar is served without processing by default on Apache. I haven't checked Nginx but I assume it's the same.

Do people see any problems with this approach?

[Michael Strong]

Nope, sounds good. ZF2 already does this: http://framework.zend.com/manual/current/en/ref/installation.html

--

You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to silverstripe-d...@googlegroups.com.
To post to this group, send email to silverst...@googlegroups.com.
Visit this group at http://groups.google.com/group/silverstripe-dev.
For more options, visit https://groups.google.com/d/optout.

[Ingo Schommer]

BTW, the lumen-installer simply downloads a ZIP from a fixed location: https://github.com/laravel/lumen-installer/blob/master/src/NewCommand.php#L80

Makes the initial "time to installer screen" fast, you'll just have to wait for the same download size to come through a bit later in the process.

And it still requires having composer installed in the first place. So don't think that's a great option.

Including composer.phar in the ZIP download seems like a good way to spread its use for modules, at the relative expense of another MB in the download.

Now that we have the archives on S3 that's even less of an issue in terms of transfer speed.

[Sam Minnée]

FYI I've added a ticket to actually implement this:

https://github.com/silverstripe/silverstripe-buildtools/issues/8