Dev Requirements

[composer]

Dev Requirements

[Seldaek]

IMO this is problematic. Imagine you want to patch a library you use in your project, and run its test suite. You need to reinstall it from source first, so you do composer mark-dev lib then composer update and you now have the lib, including it's require-dev deps installed in your project. You go and work in that lib, and then run the test suite, but it fails because the deps were installed in your project, so you have to do composer install --dev in there to get the deps again.

The only way I see around that is that in test suites bootstrappers, you always check for an autoload.php in ../vendor/.composer/autoload.php AND if you're being wrapped, ../../../.composer/autoload.php. This sort of sucks. Therefore I think binding dev-requires to the source install is not the right thing.

[henrikbjorn]

what about a --install-dev-requirements for the command line utilities. That would fix it correct ?

[Seldaek]

I'm not sure what you mean.

[henrikbjorn]

Like we have a --install-suggests then have a --install-dev-requirements and have group title like "suggest" called "dev-require"

[henrikbjorn]

Basically like @naderman suggests but with an additional command line option

[Seldaek]

Well, that doesn't really change the problem I described above.

[stof]

+1 for adding dev requirements. You can have libraries needed only to run the testsuite of your project and totally useless when installing the package otherwise. Good examples: Behat or PHPUnit :)

[henrikbjorn]

for now my work around is adding those to suggests

[simensen]

I think that something like dev requirements (--install-dev-requirements) would be great. I think it should be decoupled from the --dev that triggers installation/update from source, though. To me it is two separate things. Being able to do active development on a project's dependencies vs. being able to have access to additional dependencies (for testing, etc.) while doing development. (Should also support combining --dev --install-dev-requirements)

Also, maybe --dev could stand to be replaced with something like --prefer-source as that seems to be a better description of what that flag does.

[simensen]

Ran into "dev requirements" type functionality working on a Ruby project last night and it reminded me that this would be a good idea for Composer. Gems implementation for future reference: spec.add_development_dependency()

[simensen]

--dev is now --prefer-source per #294. I think this frees up --dev to be used for this purpose (meaning: to install dev requirements) though I think that --install-dev-requirements is probably a better choice as it fits better with the "install suggests" and "no install recommends" already being used.

[stof]

--install-dev may be enough and is shorter. Keep in mind we don't have autocompletion for them :)

[henrikbjorn]

It should be possible to generate a zsh or bash completion script from the commands.

[wilmoore]

Might also want to look at how bundler handles this (fairly elegantly in my opinion): GROUPS (:group or :groups)

[Seldaek]

I'm not sure if a full group feature is really required. The main use case even in their docs seem to be "dev" and test" groups, which to me sound very similar, since devs should run tests. There aren't so many contexts in which you use a library. Either it's for consumption/production, or you are working on it and need the full deps.

[wilmoore]

@Seldaek I understand that sentiment; however, what about the creative usages that have not been thought about. Closing the door to that leaves a lot on the table. With that being said, what is the harm in allowing this flexibility (hack-ability)?

[Seldaek]

My main concern was to find the proper syntax for multiple groups, but I gave it some thought and I guess one way we could make this work is just allowing free-form require-* keys, or perhaps inside the require key allow subgroups. So that would be:

"require": {
    "requirement/a": "1.1.0",
    "dev": {
        "some/test-package": "1.0.0"
    }
}

"require": {
    "requirement/a": "1.1.0",
}
"require-dev": {
    "some/test-package": "1.0.0"
}

Basically those deps are never installed unless the package is the root package and it's installed with some optional flags, so they can be completely ignored by default (and by packagist etc), so that makes things easier. If you call install --group=dev we would just enable those packages in addition to the default ones for this call. It might also help make #183 unnecessary (ping @lsmith).

Still not sure how we handle the lock file in that model though.

[henrikbjorn]

i like the

"require-dev" {
    "some/test-package" : "1.0.0"
}

[wilmoore]

The nested groupings seem more nature to me. If I were to try to do groups without reading the documentation, I would try nesting first.

"require": {
"requirement/a": "1.1.0",
"dev": {
"some/test-package": "1.0.0"
}
}

+1

[schmittjoh]

I find the nested grouping not so obvious tbh, and it would also imply that you can also do this for other keys like "recommend", or "suggest" which afaiu you cannot?

Would the "require-dev" packages be merged into the "require" packages, e.g. could I overwrite the version of Symfony for example to have one group for 2.0 and another for 2.1?

[Seldaek]

I guess we could merge. And yeah I agree the nested version doesn't sound too nice to me, it looks better but might be more confusing.

[stof]

+1 for require-dev

[naderman]

To always have a usable lock file, we should run the solver twice. One for just require, which results in a regular lock file, and then a second time for require-dev with previously installed packages in the installed repository. The lock file should then get an extra section to lock all files installed in this second phase. This part of the lock file will be ignored if someone doesn't use --group=dev in their install command. require-dev should never be allowed to override any choices of require, to avoid situations where a package works with require-dev but is broken with just require. This is easily done by requesting the precise versions of packages stay installed while solving require-dev.

Multiple groups become difficult to handle, since we need to define their order and exclusivity/combinability. So we should just stick to require-dev. We might also want to call the option --dev rather than --group=dev then.

[schmittjoh]

If I understand you correctly, then it is not possible to run the tests
against Symfony 2.0 and Symfony 2.1 with your proposal unless I duplicate
my composer file as I can do already, am I correct here?

On Thu, Mar 29, 2012 at 9:29 AM, Nils Adermann <
[email protected]

wrote:

To always have a usable lock file, we should run the solver twice. One for
just require, which results in a regular lock file, and then a second time
for require-dev with previously installed packages in the installed
repository. The lock file should then get an extra section to lock all
files installed in this second phase. This part of the lock file will be
ignored if someone doesn't use --group=dev in their install command.
require-dev should never be allowed to override any choices of require, to
avoid situations where a package works with require-dev but is broken with
just require. This is easily done by requesting the precise versions of
packages stay installed while solving require-dev.

Multiple groups become difficult to handle, since we need to define their
order and exclusivity/combinability. So we should just stick to
require-dev. We might also want to call the option --dev rather than
--group=dev then.

---

Reply to this email directly or view it on GitHub:
#78 (comment)

[henrikbjorn]

If there is created two groups in the lock file then i think it should be possible to change the required packages in a require-dev.

[naderman]

@schmittjoh No, that would not be possible. But it wouldn't have been possible with what was proposed before either. You would always have had to duplicate your composer file to specify a different value in require-dev.

[naderman]

@henrikbjorn The dev part of the lock file will only contain packages to be installed in addition to the main list of lock file packages, so no that won't be possible.

[schmittjoh]

@nils, that's why I'd like to merge the require-symfony2.0 group into the
require group when running with "--group=symfony2.0". Analogue that would
work for a "--group=symfony2.1". This also could be limited to run Composer
with one group only if it otherwise gets too complex, or the groups could
be merged in the order in which they are passed as command line options.

This would simplify the travis integration a lot.

On Thu, Mar 29, 2012 at 9:52 AM, Nils Adermann <
[email protected]

wrote:

@henrikbjorn The dev part of the lock file will only contain packages to
be installed in addition to the main list of lock file packages, so no that
won't be possible.

---

Reply to this email directly or view it on GitHub:
#78 (comment)

[naderman]

So then how do you deal with the lock file in that case? Does the lock file always contain whatever you last ran install with?

[naderman]

As for travis integration Jordi has already proposed a require command which simply modifies your composer.json to include an additional requirement, this would work perfectly fine for travis without any of these odd new features

[schmittjoh]

Well, the lock file does not really matter to me in that scenario, and I wouldn't commit it.

As for end-user applications where the lock file is committed, I do not see much use in the "--group" feature there.

[naderman]

End user applications have and run tests too? I really don't see the difference there.

[schmittjoh]

But you don't run against two different symfony versions, do you? For
libraries it makes sense to me, but if I'm choosing Symfony2.1 for my
application, I don't care whether tests pass with Symfony2.0.

On Thu, Mar 29, 2012 at 11:54 AM, Nils Adermann <
[email protected]

wrote:

End user applications have and run tests too? I really don't see the
difference there.

---

Reply to this email directly or view it on GitHub:
#78 (comment)

[naderman]

Well for one thing I also commit lock files for libraries to synchronise among developers. And additionally you seem rather focused on Symfony. I find it perfectly normal that someone would write an application which they want to test with two different libraries, say mysql/postgresql support or even different versions of the same, to make sure the app runs on different PHP versions for example.

[schmittjoh]

I don't have had the need yet, but looking at Doctrine I can say that the
group feature is not necessary when you want to test against different
server set-ups (available extensions/php versions/other software). If it
comes to test against different PHP library dependencies, that's where it
gets interesting for me, and what I'd like to see improved somehow.

On Thu, Mar 29, 2012 at 12:12 PM, Nils Adermann <
[email protected]

wrote:

Well for one thing I also commit lock files for libraries to synchronise
among developers. And additionally you seem rather focused on Symfony. I
find it perfectly normal that someone would write an application which they
want to test with two different libraries, say mysql/postgresql support or
even different versions of the same, to make sure the app runs on different
PHP versions for example.

---

Reply to this email directly or view it on GitHub:
#78 (comment)

[naderman]

I think you misunderstood. What I described is a situation where a PHP library is available only up until a certain PHP version, and then after that a newer version of the library needs to be used which no longer supports the older version of PHP. So if you want to support both versions of PHP, you must support both versions of the library, then you would need to start testing your app against multiple versions of a library.

Anyway as I already said, Jordi came up with a workable solution for that, and it's certainly not require-dev. Require-dev is meant to install tools that are necessary only during development.