4577 Posts in 1388 Topics by 1377 members
Page: 1 2
|Go to End||Next >|
16 November 2012 at 6:59am
Hi, I'm just testing out using Composer to install a site and modules by following the instructions here: http://doc.silverstripe.org/framework/en/installation/composer
The site installs fine and I'm able to set it up through my browser. However, I'm having problems running 'composer update', or installing modules such as 'composer require silverstripe/subsites:*'.
I basically get the same error message:
"composer.json has been updated
Loading composer repositories with package information
Your requirements could not be resolved to an installable set of packages.
- The requested package silverstripe/cms 1.0.0 could not be found.
- The requested package silverstripe/framework 1.0.0 could not be found."
Any ideas what's happening here? Thanks
16 November 2012 at 9:18am
Having had a closer look at the files I tried updating the composer.json file and this seems to have done the trick.
Initially there's a section that says:
I changed this to:
I don't know if this is the correct thing to do, but it seems to work. If anyone can tell me if what I've done is ok that would be much appreciated. Thanks.
21 November 2012 at 9:26pm
Thanks for that, got me past the same problem.
22 November 2012 at 1:42am Last edited: 22 November 2012 1:42am
With the addition of the blog and forum modules, I ended up with the following in my composer.json file:
"description": "The SilverStripe Framework Installer",
I had to set the version number for the framework and cms explicitly as otherwise the head of master was used, which is not what I want.
22 November 2012 at 6:02am
The "composer create-project" command is trickier than it looks...
If you install from a tag like 184.108.40.206, it'll use the github-generated ZIPs by default, for both root and dependencies.
Which means it can't infer version information from git on a "composer require" or "composer update" call.
You can verify which version composer thinks its on by using "composer show --self".
Using the ZIPs is much, much faster than a full git checkout, so in general its a good default,
if it wasn't for that limitation around version introspection.
Symfony gets around this by requiring release branches in their composer.json, rather than "self.version":
That's not great either though, as it means "create-project" with a tag argument is not actually respected in dependencies.
Some stopgap fixes:
- install from a branch (3.0.x-dev)
- use the "--prefer-source" flag
I think in the end, composer needs to track this information somewhere in its metadata.
22 November 2012 at 7:27am
Thanks for the feedback, I will read the discussions tomorrow
22 November 2012 at 4:34pm
Ok I think I understand the issue with version introspection now, thanks for your detailed reply. Looking at the symfony example, it does look like version numbers need to be hardcoded in composer.json which is not ideal, as it prevents the automatic update for new versions of modules when running composer update. In effect, it is almost like creating the lock file.
The documentation for installing SilverStripe using Composer is with respect to the above problems incorrect and needs fixing. Is open.silverstripe.org the most appropriate place to register a documentation issue?
22 November 2012 at 6:18pm
I think the fix we need to make is to patch silverstripe/installer (github.com/silverstripe/silverstripe-installer) to have hard-coded version references.
Perhaps we can do this before 3.0.3?
Page: 1 2
|Go to Top||Next >|