Remove namespaces?

[bamarni]

Remove namespaces?

[bamarni]

The one in the readme is probably not the best example, but in the case of Behat it is common to have additional packages alongside (Mink extension, Mink drivers, Custom contexts, ...). So forcing 1 package per namespace would be too restrictive here.

It is still possible to do isolated namespaces, maybe composer bin phpspec require phpspec/phpspec:^2.0 sounds a bit redundant, but then you can just do composer bin phpspec update. Having an explicit namespace also allows this plugin to stay simple, it's basically just a small script which changes directory to vendor-bin/{namespace} before running the composer command.

[theofidry]

So forcing 1 package per namespace would be too restrictive here.

Makes sense

Having an explicit namespace also allows this plugin to stay simple

Indeed it helps to keep it more simple, but ultimately the best would be to have this plugin work in a complete transparent for the user:

• not having to manage namespaces unless wanting to it manually (like for the bdd example) which is the most common use case IMO
• having the composer install and update apply to binaries as well (they are still dependences, not of your application itself, but of your project still)

[bamarni]

not having to manage namespaces unless wanting to it manually (like for the bdd example) which is the most common use case IMO

Do you have an example on how it would look like (what commands to run to install / update a tool for example)? It'd be a bit more user-friendly indeed, but I don't see how this feature could be implemented.

having the composer install and update apply to binaries as well (they are still dependences, not of your application itself, but of your project still)

It can be done with post install / update scripts, there is an example in the readme.

[theofidry]

It can be done with post install / update scripts, there is an example in the readme.

I saw it, but isn't there a way to hook them automatically? Well, wouldn't be surprised if not but that would ease the setup process and make it less error-prone.

not having to manage namespaces unless wanting to it manually (like for the bdd example) which is the most common use case IMO

Do you have an example on how it would look like (what commands to run to install / update a tool for example)? It'd be a bit more user-friendly indeed, but I don't see how this feature could be implemented.

composer bin require phpspec/phpspec:^2.0 which would be equivalent to composer bin phpspec_phpspec require phpspec/phpspec:^2.0?

In the case of not specifying a namespace, you don't really care what the namespace is, what is more ticky is how to manage it afterward if you want to remove it for example.

Also as there is symlink, how are binaries managed if there is the same one for different packages? E.g. say you are installing packageA which as a binary pA in a namespace and then another one packageB with a binary pB. packageB has a dependence on packageA so it has two binaries: pA and pB. How would you handle that conflict?

[bamarni]

I saw it, but isn't there a way to hook them automatically? Well, wouldn't be surprised if not but that would ease the setup process and make it less error-prone.

That should be possible to do with an event listener. For auto-install things are not optimal at the moment, as the suggested hook would install the cli tools even in production. The plugin should probably be used as composer bin namespace require-dev ... instead of require, then the auto-installation would also forward the --no-dev flag.

In the case of not specifying a namespace, you don't really care what the namespace is

Given the way this plugin works, it is actually important for users to be aware that there is a namespace. Knowing it is needed for later interactions with it after it has been installed.

Also as there is symlink, how are binaries managed if there is the same one for different packages? E.g. say you are installing packageA which as a binary pA in a namespace and then another one packageB with a binary pB. packageB has a dependence on packageA so it has two binaries: pA and pB. How would you handle that conflict?

This is not supported, but I'd say not common at all as cli dependencies are usually in require-dev. If the case you mentioned exist, packageB is most likely requiring more than it needs, if he's nice enough maintainer of packageA could probably extract a useful library out of it :)

I was also thinking about such cases, it was more about the possibility to allow different versions of the same tool, by using separate namespaces. But I didn't give it more consideration as it's not the original purpose of this plugin.

[bamarni]

Also, I don't know if / how you plan to use this plugin, but personally I'm just creating one namespace called "cli", and only in big projects with a lot of deps. I don't really see the point in having one cli tool per namespace, unless they have dependency conflicts between them.

[theofidry]

Basically my idea was to manage my project dependencies via Composer. By project dependencies I mean dependencies required for various purpose on your project, but not require to make your application work. For example PHPUnit for running some tests or a static code analysis tool.

For now I see 3 solutions:

• A) Download them each time, specify in the doc which phar your need and which version.
• B) Download the binaries and commit them. This greatly increase your repository size and presents some issues for managing versions. For example on a PHP5.4 Travis build, PHPUnit must be 4.x, but on PHP5.6+ it's PHPUnit 5.x, unless your commit several versions of your phar you have to manually update your binary version... Annoying when doable.

A problem in those cases is that you must rely on binaries, i.e. the library must build them and be able to manage the versions of the phar.

What I would hope to achieve with your plugin is to instead specify those project dependencies via Composer. As such, libraries would no longer require to have phar and the version management is left to Composer. Everything done without polluting your application dependencies.

[bamarni]

For example on a PHP5.4 Travis build, PHPUnit must be 4.x, but on PHP5.6+ it's PHPUnit 5.x

Not necessarily, I think phpunit 4.X can be used for PHP 5.4 and 5.6+ as well.

By project dependencies I mean dependencies required for various purpose on your project, but not require to make your application work. For example PHPUnit for running some tests or a static code analysis tool.

Just to make sure we don't miss the obvious, why not using require-dev?

To make it clear about this plugin, it's only useful if you have dependency conflicts between your application libraries and cli tools.

[theofidry]

Not necessarily, I think phpunit 4.X can be used for PHP 5.4 and 5.6+ as well.

Yeah but not PHPUnit 5.x, that said maybe in that case it's better to stick to php 4.x :/

Just to make sure we don't miss the obvious, why not using require-dev?

Because when I'm using tools like phpunit or phpmetrics, they are dedicated applications, not an application dev dependencies and doing so brings a lot of issues. To quote qossmic/deptrac#87 (comment):

i'll try hard to avoid unnecessary breaking changes. if you use deptrac as phar you would be just affected by breaking changes on cli arguments and the depfile. imagine i would update deptracs dependencies to symfony 3.0 or 2.3 - may this would break your code. to bring deptrac to the next level it's important that i can update it's dependencies without any thoughtfulness.
deptrac comes with a composer.lock file. if you've any issue with deptrac, i'll take care of it. if you omit deptrac's lock file, it's "your problem".
for example deptrac has a dependency to sensiolabs-de/astrunner (dev-master). if you omit deptrac's lock file, you may will end up with a unsupported astrunner version.
your project shouldn't care about deptrac's dependencies at all. for example why should your project has a dependency to graphviz or twig? one of deptrac's goal is helping to avoid unnecessary / wrong dependencies. By requiring deptrac as a project dependency, you just would add more useless project dependencies.
less dependencies are better
i think there are more reasons why it's a good idea to keep deptrac as a separate application. can you empathize why i believe in the idea that using a phar file would be the best solution (for now)?

[bamarni]

Well if that's your approach why not. You could add this plugin in your project's require-dev and then use it to manage cli tools.

[theofidry]

Actually I'm better off with namespaces. If you just have phpunit it's a bit overkill and that's a case where namespaces are useless, but most of my projects have more than phpunit :)