Skip to content

create-project with dist/tag checkouts fails to resolve self.version constraints #1351

chillu opened this Issue Nov 22, 2012 · 10 comments

4 participants

chillu commented Nov 22, 2012

We're recommending to install SilverStripe through this command, very exciting that one-liner installs become a reality! But this bug stops us from using it effectively:

composer create-project silverstripe/installer my-folder points to a tag, which means create-project defaults to checking out github ZIP files from what I can tell (no version information present). That's a good default, since its much faster.

But our composer.json has self.version references on dependencies which break with this method (see forum post).

This can be fixed by using --prefer-source, checking out a branch, or hardcoding versions in dependencies. There's also the COMPOSER_ROOT_VERSION env setting as described in #1089.
None of those is a good fix in my opinion. Would it be possible to somehow store the version in composer metadata when using create-project?

composer create-project silverstripe/installer test
Installing silverstripe/installer (
  - Installing silverstripe/installer (

Created project in test
Loading composer repositories with package information
Installing dependencies
  - Installing composer/installers (dev-master a3d52d8)
    Cloning a3d52d8414ec26533a540ebacbc1c20be568c83f

  - Installing silverstripe/framework (

  - Installing silverstripe/cms (

  - Installing silverstripe-themes/simple (dev-master 5779d77)
    Cloning 5779d770dc3cd9bf6f839b747a456f81d00a8329

Writing lock file
Generating autoload files
composer show --self
name     : silverstripe/installer
descrip. : The SilverStripe Framework Installer
keywords : 
versions : * 1.0.0
type     : library
license  : 
source   : []  
dist     : []  
names    : silverstripe/installer

php >=5.3.2
silverstripe/cms self.version
silverstripe/framework self.version
silverstripe-themes/simple *

requires (dev)
silverstripe/compass *
silverstripe/docsviewer *
composer update
Loading composer repositories with package information
Updating dependencies
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - The requested package silverstripe/cms 1.0.0 could not be found.
  Problem 2
    - The requested package silverstripe/framework 1.0.0 could not be found.

Potential causes:
 - A typo in the package name
 - The package is not available in a stable-enough version according to your minimum-stability setting
   see <> for more details.

Read <> for further common problems.

System info: Composer version 2de2e95

P.S.: Not entirely sure if this is a duplicate of #1229.

Composer member
Seldaek commented Nov 22, 2012

May I ask why you require self.version though? Sounds to me like should work with any 3.0.* at least, of course they will have small bugs and ideally you want to use the latest, but why restrict it to absolutely the same version?

self.version was really just added to make mass-replace stuff easier like Symfony2 and ZF2 do, because otherwise they'd have to keep updating them at every release. In those case you really want to target one specific version otherwise you are lying to the solver and bad stuff happens.

In your case though I don't see what requires such tight coupling of versions.

chillu commented Nov 22, 2012

Thanks for the fast response! Maybe we're mis-using create-project as the primary way to install our software releases. We basically see it as a convenient replacement for downloading archives, so fixed and manually regression tested release points. That's in addition to automated testing and keeping API changes out of micro-releases, of course.

Symfony seems to go down the same route of suggesting create-project as the default installation: - I was actually a bit surprised that it gets the 2.1.3 tag for the "standard-edition" root project, but the 2.1.x branch for "symfony/symfony".

So, in terms of release management, we as project creators might decide to push people more into using the latest release branch, but that's independent of the composer abilities, right?

That being said, it's going to be confusing to devs if a composer update doesn't have any effect on some dependencies because they're fixed to a tag (via self.version) which was set through the initial create-project call, and is hidden in some internal metadata, rather than in git repo information.

So, I don't really see a good solution - unless you have other suggestions, feel free to close the ticket. Might be worth adding a note to create-project that its not supposed to be used with self.version placeholders :)

Composer member
Seldaek commented Nov 22, 2012

Well, I think what might be best is that you ship a lock file with your project. That way you can safely use 3.0.* instead of self.version, just make sure you tag dependencies first, then update the lock file, and then tag the main project. That way people can use it as an easy install method (which is perfectly fine IMO), and they'll install from the lock file by default which will contain the latest releases at the time of tagging (which is most likely equivalent to self.version). Then if they run update, they'll get newer updates at least. With your self.version scheme they could never update dependencies which sounds wrong to me.

stof commented Nov 22, 2012

and you are also forced to do a release of all your deps when doing a bugfix, even if these deps have not changed at all (because self.version would require the newer version)

chillu commented Nov 22, 2012

Awesome, I think composer.lock is a viable solution, thanks heaps guys!

@chillu chillu closed this Nov 22, 2012
sminnee commented Nov 22, 2012

@stof, @Seldaek: the comment about "forced to do a release when doing a bugfix" isn't really relevant to this project, because the installer is quite a thin shell around everything else - the chance that we have a fix in installer but nothing to release in cms and/or framework is pretty small.

There is an underlying issue here - regardless of what should be done, the use of self.version in packages called with create-project is currently broken.

The fix would be to rewrite "self.version" values in require and require-dev to the current version number prior to the .git folder being removed.

If I wrote such a patch, would it be accepted?

Composer member
Seldaek commented Nov 22, 2012

@sminnee that sounds like a good idea yes, at least if done only when git is removed or the package was installed from a zip (dist).

stof commented Nov 22, 2012

@Seldaek In fact, the create-project command should probably set the root version in the config according to the package it installed, before calling the installer.

but this would still break later when running composer install again if the root package contains self.version

Composer member
Seldaek commented Nov 22, 2012

@stof I think @sminnee's proposal sounds better. The most important is that this becomes a usable project file.

@sminnee sminnee added a commit to sminnee/composer that referenced this issue May 9, 2013
@sminnee sminnee NEW: Rewrite self.version in create-project (Fixes #1351)
When composer create-project is called and the resulting project is disconnected from the
parent repo, self.version references no longer work.  To fix that, this patch rewrites
self.version to the actual version number as part of 'composer create-project' execution
sminnee commented May 9, 2013

And 6 months later, I actually come up with something. ;) #1883

@digitalkaoz digitalkaoz pushed a commit to digitalkaoz/composer that referenced this issue Nov 22, 2013
@sminnee sminnee NEW: Rewrite self.version in create-project (Fixes #1351)
When composer create-project is called and the resulting project is disconnected from the
parent repo, self.version references no longer work.  To fix that, this patch rewrites
self.version to the actual version number as part of 'composer create-project' execution
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.