Comments (11)
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.
from composer-bin-plugin.
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)
from composer-bin-plugin.
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.
from composer-bin-plugin.
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?
from composer-bin-plugin.
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.
from composer-bin-plugin.
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.
from composer-bin-plugin.
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.
from composer-bin-plugin.
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.
from composer-bin-plugin.
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)?
from composer-bin-plugin.
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.
from composer-bin-plugin.
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 :)
from composer-bin-plugin.
Related Issues (20)
- Call to undefined method when updating to 1.7.0 HOT 2
- Plugin fails to work with Composer < 2.3
- Call to undefined method during (and only during) the update from 1.5.0 to 1.7.0 HOT 2
- Plugin (still) fails to work with Composer < 2.3 HOT 1
- Compatibility with `Composer\InstalledVersions` API HOT 4
- Can outdated command be forwarded as well? HOT 5
- Inherit from github-oauth main composer.json HOT 2
- Create autoloader that include all package namespaces HOT 2
- Reuse existing packages via symlink HOT 2
- Detect installation via this plugin HOT 10
- Warning appears if multiple namespaces contain the same custom Composer script name HOT 2
- `composer update --lock` invokes `composer update` HOT 2
- Composer plugin support in namespaces? HOT 6
- Composer cache dir seems not be respected HOT 3
- No-Dev installation fails when defined as dev dependency HOT 2
- Dev-Dependencies installed when using --no-dev option HOT 1
- Doesn't work with ergebnis/composer-normalize HOT 6
- Drop support for PHP 5.x HOT 1
- Forward command not executed on first install
- Error with composer when using this plugin and it's allowed in `composer.json` HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from composer-bin-plugin.