search

composer / composer

Dependency Manager for PHP
https://getcomposer.org/
MIT License
28.32k stars 4.47k forks source link

Allow Plugins and/or Script to modify versions before packaged is parsed/fetched. #2775

Closed davidbarratt closed 10 years ago

davidbarratt commented 10 years ago

Since Drupal is in the process to Consider composer.json to manage dependencies instead of .info files, is it possible to modify a required version number before it is parsed by Composer?

For instance, if a Module's version is "7.x-3.5", would it be possible to use a plugin/script to modify it to "3.5" to allow it to be processed normally?

I suppose this does not completely fix the problem in Drupal though because it is possible for a module to have a "6.x-3.5" version and a "7.x-3.5" version. Is there any way to work with this without having to modify Composer and without having to change all of the version numbers?

Seldaek commented 10 years ago

Can we please consolidate this discussion in one place? I don't care where, but you're not the only drupal person to stop by and ask things, and it sounds counterproductive to have the same talk with different people every few months. So can I know who's in charge of this on the drupal end then we can try to discuss it to the end once so you can move forward?

/cc @patcon @crell @donquixote

davidbarratt commented 10 years ago

My Question really wasn't Drupal specific as any non-X.Y.Z format version numbers would need the ability to modify the way Composer works (via a plugin?). However, Drupal seems to be the only X.Y.Z project that comes to mind (I doubt that it is though).

I attempted to search for a similar question but I didn't find it. If you could link me to the duplicate that would be amazing.

I'm not sure what "this" is, but I'm assuming you are asking for who is in charge for making a decision like this? (i.e. changing version numbers for every module on drupal.org).

That would be the Drupal Maintainers: https://github.com/drupal/drupal/blob/8.x/core/MAINTAINERS.txt

More specifically, the Branch maintainers: https://github.com/drupal/drupal/blob/8.x/core/MAINTAINERS.txt#L6

I hope this helps. I apologize for causing more problems.

Thanks!

patcon commented 10 years ago

Sorry, I think it's safe to say I'm away from Drupal at the moment

Crell commented 10 years ago

Hm. Is there another thread we should be following instead? (I wasn't aware there was another discussion of changing version number handling.)

patcon commented 10 years ago

I think he just means a meta-thread for getting composer working for Drupal (core and/or contrib). I can't imagine that visiting drupal.org is in his routine/flow, so it's pretty demanding to follow all those massive threads :)

Seldaek commented 10 years ago

Yes, people come talk to me directly every now and then and I've a feeling this leads nowhere but whatever I'll answer here and hopefully it makes it's way to where it'll be most useful.

And sorry to be blunt but it's late and I don't have much time so here comes: 7.x-3.5 as a version is kinda nuts. I get why drupal went there but it's not gonna happen in composer, and I doubt any amount of monkeypatching can fix that. I see two solutions:

I can't tell which is the best approach given the constraints you live with, but I'd pick the first in a perfect world.

P.S.: in composer, most packages define their versions using git/svn/hg tags, and not within the composer.json file. I'm not sure if this is clear to you or not, and I'm not sure how the .info thingy works or how it would likely evolve if it were to be ported to composer as a concept, but it sounded important to bring to your attention.

patcon commented 10 years ago

:heart:

donquixote commented 10 years ago

@Seldaek i think there is no one single discussion of "how can Composer work with Drupal". What we see is different people independently exploring the possibilities. For some, the goal is to download all Drupal modules with Composer. Others only want to use Composer to download additional packages, while Drupal modules should be handled by the drupal.org infrastructure. And then there is a difference of whether we are talking about Drupal 7, 8 or 9, or Drupal contrib. E.g. the "download additional packages with Composer" would apply to Drupal 7 contrib and Drupal 8 core / contrib, but "download everything with Composer" could apply to Drupal 9. (although some people might see this differently)

I think the way to handle this on the Composer issue queue is to discuss things in a way that still makes sense without Drupal in the mix, and only treat Drupal as a specific use case. E.g. if Composer is going to introduce new flex points to modify package versions, this should be done for a better reason than "needed by Drupal".

donquixote commented 10 years ago

@davidbarratt: In addition to what Seldaek said above: Typically, or at least traditionally, we have separate module version for different generations of Drupal core. We should definitely not use any part of the semver number to indicate core compatibility. Some other options that come to mind:

(and I apologize, I just violated what I said in my previous post. This is totally Drupal-specific)

stof commented 10 years ago

@donquixote The way we do it for composer packages is to have a version number based on the package only. The compatibility with Drupal would be handled by dependency requirements

donquixote commented 10 years ago

@stof: the challenge is we want to publish different versions of the same module for different generations of drupal. we would have to express all of this in the first number of the semver. e.g. mymodule 1.x.x and 2.x.x for drupal 7, then 3.x.x for drupal 8, an then what if i decide i want a new major version for drupal 7? name it 4.x.x? this will be confusing for everyone. my previous post shows some ways out. On Mar 4, 2014 9:16 PM, "Christophe Coevoet" notifications@github.com wrote:

@donquixote https://github.com/donquixote The way we do it for composer packages is to have a version number based on the package only. The compatibility with Drupal would be handled by dependency requirements

Reply to this email directly or view it on GitHubhttps://github.com/composer/composer/issues/2775#issuecomment-36668930 .

Seldaek commented 10 years ago

Since composer supports 4 bits of info in the version, you could abuse that and have an off-by-one error for drupal modules e.g.: 7.3.5.0 for D7, 8.3.5.0 for D8 etc. Releasing a 7.4.0.0 and 8.4.0.0 would be a BC breaking release, you just gotta learn to skip the first digit.

Anyway I'm closing this because it has nothing to do with composer really but feel free to go on discussing. I don't mind if it happens here I just hope all interested parties will read it.

donquixote commented 10 years ago

Since composer supports 4 bits of info in the version

I was not aware of this - nice to know :)

I still think that the solutions in https://github.com/composer/composer/issues/2775#issuecomment-36662791 could be preferable and less confusing.

@Seldaek sorry to ping you again for this, but are there any restrictions on the package and vendor name? E.g. could you have more than two fragments? Like donquixote/Drupal/8/coolmodule? Or donquixote/Drupal/coolmodule/D8..

Seldaek commented 10 years ago

Composer doesn't care (it just treats the name case-insensitively), packagist only allows foo/bar. So if it's your own package repository you do what you want, but then you also need a custom installer to strip all this garbage from the path I guess.