Comments (13)
My ideal solution would be this:
path = consumer.extra.installer-paths || package.extra.installer-path || package.type;
Ultimately the consumer has the option to control the install path with extra.installer-paths
. The package author can suggest an install path auto-determined by the package type
or directly through a extra.installer-path
.
#20 solves this naming issue but I think it's cumbersome to ask package authors to instruct consumers to include the extra.installer-paths
lines in their composer.json.
from installers.
I personally feel that naming a package without a framework identifier is better. I had the same issue with one of my packages, cakeftp and I ended up using the name shama/ftp
in composer and specifying cakephp in the keywords. I really I wish I would have just named that package Ftp
as it helps when installing via git as well.
With #10, you could do this when you install:
{
"require": {
"uzyn/cakephp-aws-datasource": "*"
},
"extra": {
"installer-paths": {
"Plugin/AwsDatasources/": ["uzyn/cakephp-aws-datasource"]
}
}
}
I know there are a lot of existing cake packages that prepend cakephp- or cake. Some have even more explicit package names but need to install to a different name (https://github.com/nodesagency/Platform-API-plugin). So you might be the first of many to file an issue about this.
It wouldn't hurt to propose an additional extra field for overriding the package name and get a response. I'm for it.
from installers.
I've just submitted a pull request. I still feel that having a framework identifier makes some sense, it makes searching on Packagist clearer.
Also, I feel that sometimes a user may not always have the full liberty to name a package what he/she wants. For example, I developed an Opauth (uzyn/opauth
) plugin for CakePHP and call it uzyn/cakephp-opauth
. That way if I am to make an Opauth plugin for another framework, I can prepend the framework name and still host it under my account / namespace, eg. uzyn/yii-opauth
.
from installers.
D'oh. Missed this discussion before answering in #22. Sorry for being ignorant about CakePHP, but what is the effective difference between having something installed as plugins/lala and plugins/cakephp-lala?
from installers.
@Seldaek For the case of CakePHP, it would break the CakePHP convention and plugin path discovery. There are then more steps required for plugin user to specify custom paths for a plugin that it would makes no sense to use this installer anymore rather than just asking users to git clone git-url proper-dir-name
.
I'm fairly sure this is not unique to CakePHP, besides also breaking PSR-0.
from installers.
As @Seldaek pointed out at #22, yes one can do it via #20 's installers-path
, but I feel that these 2 extra properties serve different purpose.
installers-name
is a little more "lightweight" as compared to installers-path
in a sense that the former is only specifying a custom name. One example where this would make a diff is that if a framework were to update its default plugin directory, packages with installers-name
can still leverage on composer/installers
update and be installed in the correct dir. Another use case is for overwriting the installer's default inflected package name, eg. an author of a package may prefer FTP
instead of Ftp
.
from installers.
@shama ah well, I guess you are right. But I would rather not have package.extra.installer-path be a full path, I'd rather have just a installer-name one that just overrides the vendor/name
couple to foo
. Or maybe even just the name part, so you can have a shama/cakephp-zomg plugin, and it installs in cake's plugins/shama/zomg if you specify installer-name zomg. It just allows you to clean up the cakephp- prefix. But then again this could maybe be done by the installer itself if it's a common enough pattern.
To sum up I think this whole thing is a mess and I'd rather not have it, but if you really must I think I'll have to trust you on the requirements. From where I stand, the fact that this is needed just highlights a problem in cakephp - path discovery is a common pattern, but it is a really annoying one.
from installers.
@Seldaek CakePHP, as well as many other frameworks were around before autoloading. Each had to develop their own path convention. I see this issue and project as embracing other conventions rather than trying to force a Composer convention. You could call it a CakePHP or framework X problem if Composer existed when these decisions were made. Unfortunately we all weren't so lucky. ;)
I understand why you don't want these changes. It is pretty much impossible to remove the feature once implemented and adopted in the wild. So maybe a better route would be for me to fork and implement these edge case issues. Then consider introducing them to composer/installers when their necessity has been proven.
from installers.
Here is my decision on this...
Package authors are already choosing to use composer/installers and setting the type to determine the install path. They should be allowed to choose their own install path for their package as well. This will fix this name issue without needing another extra option. If a consumer doesn't like it or if a conflict occurs they can simply override it with their own installer-paths extra. After much thought and considering what installers currently allows, I don't foresee any problems with this approach and it seems to be the best and simplest solution.
Standard Author Config - installs to Plugin/{$name}/
{
"name": "vendor/name",
"type": "cakephp-plugin",
"require": {
"composer/installers": "*"
}
}
Overridden Author Config - installs to Plugin/MyCustomName/
{
"name": "vendor/name",
"type": "cakephp-plugin",
"require": {
"composer/installers": "*"
},
"extra": {
"installer-paths": {
"Plugin/MyCustomName/": ["vendor/name"]
}
}
}
EDIT: I would like to keep the interface the same but of course would not allow a package author to override another package author. The check for this config would only look for a path set for their own package.
Consumer Config - installs to app/Plugin/ConsumerName/
{
"extra": {
"installer-paths": {
"app/Plugin/ConsumerName/": ["vendor/name"]
}
}
}
This should handle the extent of install path selection in composer/installers.
@uzyn If you would like to send a PR for this let me know. I would appreciate it.
from installers.
@shama Just to check that I'm not missing anything. The difference between this and #20 is the Consumer Config part?
I generally like the idea of allowing consumer to overwrite the install paths. That's a great decision, @shama.
However, allow me to still make a last case with why I still feel the need of an installer-name
:
One of the main points, I feel, for composer/installers
is to take advantage of type
in a config and a centrally maintained (and hopefully updated) paths collection (which is composer/installers
) to let it decide the best path to install a package to.
By having users, especially authors, abusing installer-paths
to overwrite this decision greatly diminishes the purpose of this package.
- Firstly, there will no longer be a point for specifying
type
as it is simply ignored ifinstaller-paths
is present.composer/installers
would then risk to become simply a hack for Composer for specifying custom installation directories. - Secondly, should, say CakePHP 2.3 moves the
Plugin
dir to be withinVendor
(ie.Plugin/Vendor/{$name}
), a package that usesinstaller-paths
would gain no such automatic update even ifcomposer/installers
are updated with the proper path.
(It's a separate discussion altogether on whethercomposer/installers
should/would one day detect a framework version. Let's just ignore this for the purpose of this discussion.)
By having a lighter-weigh installer-name
option, a package that uses it will still benefit from the 2 points I mentioned. (On why can't the author simply name his/her package as per standard is already covered on the earlier posting on this issue).
Just thought I would make a last case for installer-name
. I will accept whatever decision the maintainers of this package make at the end.
from installers.
#20 is the consumer config and is currently implemented. I am saying we should implement Overridden Author Config option above as a solution to this name issue.
I think it is fair to say composer/installers
has always been a hack but a necessary one. It exists because number 2 on your list cannot easily happen. Until all the frameworks agree on a single package install path, composer/installers is necessary.
installer-name
could be abused as well: { "extra": { "installer-name": "../SomeDir/MyName" } }
I think if we trust an author enough to want to install and use their code... we certainly can trust them to recommend the correct install path for their package.
This would also be useful for frameworks implementing their own packagist.org (as CakePHP plans to do cakephp/plugins.cakephp.org#53). Default install locations can be set to help the existing packages migrate to composer.
from installers.
What if the name permitted a regex with named parameters? e.g.,
"Plugins/{$shortName}": ["(?:cakephp-)(?P<shortName>.*)"]
from installers.
@robocoder I think the regex patterns are very interesting but I'll wait until more people find managing their paths a problem before implementing into installers. Thanks!
from installers.
Related Issues (20)
- When target location change, data must be moved (not duplicated) HOT 3
- Path issue shows with composer installing via MAMP on macOS HOT 1
- Your app key is missing message issue
- Want to write a custom path for plug-in package? I don't know how to debug
- composer 2.3.5 breaks composer/installers HOT 3
- Disabling installer in my package will still trigger the installer path when it's pulled in a project HOT 4
- Add license to the package HOT 1
- Add version to installer-path variables HOT 1
- Add Support for "Generic" Library HOT 2
- Support https://asset-packagist.org/ types? HOT 3
- Using vcs repo without composer.json
- Add a installer for Laminas project HOT 1
- Renaming vendor breaks composer install HOT 2
- mediawiki-skin should install in CamelCase name directory
- Could we add support of wordpress-core type?
- Why are dependencies still present in the installer path after removal?
- Add support for Moodle "tiny" plugins HOT 1
- Extend documentation regarding disabling of installers
- Add partial support for the generic "library" and "project" types HOT 1
- Composer Install Installs Modules in "vendor" Instead of Specified "modules" Directory 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 installers.