Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

composer.phar /.lock with build revision information #1502

Closed
hakre opened this Issue Jan 18, 2013 · 16 comments

Comments

Projects
None yet
5 participants
Contributor

hakre commented Jan 18, 2013

I would like to see some command-line switch (and probably also something inside the docblock on top of composer.phar as well as automatically documenting it into composer.lock) to output the (full) SHA-1 of the git repository the concrete build is based on.

That should allow if the version numbering changes to keep reference to the build. E.g. if you want to document it inside the source-tree but you don't want to put the binary composer.phar blob under version control.

$ composer.phar --build-revision
e33aebc75dc64efa5c3a93503df4c93b8b4fe465

Additionally the idea comes to mind to put the revision into the composer.lock file as well so some reference is automatically kept with each update/change of that file.

Contributor

stof commented Jan 18, 2013

I don't think putting it in the lock file is a good idea. Composer is updated regularly to fix bugs but without requiring a change in the lock file.

Contributor

hakre commented Jan 18, 2013

I don't think that I have written in this feature request that composer should update the lock-file when composer.phar is updated. If you have read it that way, rest assured that this was never my intention. Instead the intention is, whenever composer updates the lockfile, it keeps a reference of it's own revision inside that file. So you can easily document with which composer revision the change of the lock-file was done (considering you put the lock file under version control).

Contributor

stof commented Jan 18, 2013

meaning that each time a different guy in the team updatesthe lock file, this revision will change. There is good chances that not everyone will have the same revision for composer as the composer website only provides the phar for tags and the latest revision, not for every commit. So if you wan each dev to use the same revision for composer, you will have to keep the phar somewhere for them to get it, or make them use composer from source.

Contributor

hakre commented Jan 18, 2013

You somehow read much more out of my lines then I ever intended to put in there. I don't want that everyone will have the same revision for composer. And I don't understand why you write that, I don't even have a clue why you expound the problems of having different composer revisions. That normally should not turn into any problems. And if it did, the last working revision would have been documented in the composer.lock file with this feature request.

Contributor

xrstf commented Jan 23, 2013

I'm also strongly against this suggestion. As @stof already mentioned, this would lead to problems in teams. Like for instance, we have around 5 developers working on a single project using Composer. Now it's highly unlikely that all of them have the same version of Composer installed.

Now evertime someone does a composer update, the composer.lock gets changed, even though no packages may have been changed. As we try to see the lock file as kind of a black box, we tell our developers to not try to outsmart Composer by analyzing the changes or (even worse) manually edit the lock file.

Contributor

hakre commented Jan 24, 2013

@xrstf: So if composer would not change the composer.lock file if it's content does not change, your problem would go away?

And I don't understand why developers try to outsmart composer by analyzing the changes or manually editing the lock file? For what should that be good?

Contributor

xrstf commented Jan 24, 2013

I think I don't understand your first question. If I have four developers working on a project and each one has a different composer version, each time someone performs an update, the composer.lock would change (at least the composer-revision-hash-string or whatever revision information shall be embedded). Sometimes, of course, the composer.lock would change because of actual updates.

Now I tell all developers "If the composer.lock changed, commit it. Do not look into the file, do not care what is says, simply commit it and leave it alone". Now if every developer does an update, I may end up with four useless commits that only change the composer-revision-hash inside the lock file. To avoid this, a developer would have to read the composer.lock prior to comitting it and see "Ah, I only changed the revision, so I can simply revert the change and not commit it". But I wouldn't want our developers to do so. They shall not view or even edit the composer.lock (at least not if they aren't 100% sure they know that they are doing).

So in the end, the revision inside the lock file would be a bad thing. Plus: How does it help? What would revision: "f528abbe23" inside the composer.lock tell you exactly? Do you want to build a matching version of a composer.phar before you install a project?

If anything, it would make sense to have Composer write something actually useful into the lock file, like a normalized version number (once it makes sense and stable releases are normal) or a list of "features" that the Composer binary that created the lock file was capable of (like features: ["tilde-operator", "branch-alias", "..."]).

Sorry if this sounded rude, I didn't intend to bash anyone :-)

Contributor

hakre commented Jan 24, 2013

@xrstf No, naturally composer.lock would only be updated for actual locking changes, not composer revision changes. Just see it as meta-data that is written only when the file needs to be written. A composer revision change alone would not qualify to trigger updating the composer.lock file. So the file does only change for what you call actual updates. Everything else - like you outline it as well - does not make sense ;)

However, I mean actually it shouldn't make much of a difference, I mean, the most important part is that the composer.lock is under version control, not which contents it has (but it was never my idea to just change it because composer.phar changed).

And I didn't read your comment as bashing, not at all, that requires a little more I'd say ;)

Contributor

xrstf commented Jan 24, 2013

Plus, if the composer.lock is under revision control, you always know when it was changed. This should be sufficient to restore the environment under which it was changed, if needed :-)

So I think this issue could be closed. :)

Contributor

hakre commented Jan 24, 2013

@xrstf: No :) - first of all not updating composer.lock for a revision change was never suggested in this ticket (so what you fear never happens). Second, this ticket is not about composer.lock specifically, that was only an addition to the feature. But thanks for your feedback, I really appreciate it.

And as you write it to restore the environment when it was changed: How do you know which composer revision did the change if you don't store the revision?

Contributor

xrstf commented Jan 24, 2013

Oh god, how embarrasing. Sorry for bragging about the lock file. ;)

In fact, getting the "build version" of composer would actually be somewhat a nice-to-have. :-)

Contributor

hakre commented Jan 24, 2013

I've read about git is able to add that with the git ident attribute and filters: http://git-scm.com/book/ch7-2.html / http://git-scm.com/docs/gitattributes - this should be able to configure via a .gitattributes file And the build script probably should read it out and add it somewhere, too.

Contributor

hakre commented Jan 26, 2013

I also can make sense to offer the "real" version number like 1.0.0 in the version switch. This could probably be useful for integration tools like the compser setup.exe on windows, see johnstevenson/composer-setup#16 (comment) .

Member

johnstevenson commented Jan 26, 2013

From the Composer-Setup viewpoint, the version number of the downloaded composer.phar is of no use whatsoever (in any format).

Contributor

hakre commented Feb 4, 2013

Sure, from the Compuser-Setup User viewpoint, the version number of the downloaded composer.phar is of informational use (especially in the human readable format). However, that is equally true for a Composer user viewpoint, the Composer Setup could only pass the version along (if). So there is no immanent use for the setup on it's own, it would be for it's users (if provided).

@Seldaek Seldaek closed this in 2b36f61 Feb 13, 2013

Contributor

hakre commented Feb 13, 2013

Thank you!

digitalkaoz pushed a commit to digitalkaoz/composer that referenced this issue Nov 22, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment