Allows for custom name that is different from package name?

[uzyn]

I'm not sure if this is related to #10, but I feel it is different.

Currently installers determine that the name for a package (for example, the name for a CakePHP plugin) to simply be $prettyName. I feel that that may not always be the best name for a package.

For example, I have a this Git repo: https://github.com/uzyn/cakephp-aws-datasources. Its name at composer.json is uzyn/cakephp-aws-datasources.
However, when it is installed as a CakePHP plugin, I would prefer it to be installed to Plugin/AwsDatasources instead of Plugin/CakephpAwsDatasources.

I could name my package uzyn/aws-datasources, but that would make it less obvious that it is a CakePHP-related package on both Packagist and GitHub.

[shama]

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.

[uzyn]

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.

[Seldaek]

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?

[uzyn]

@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.

[uzyn]

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.

[shama]

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.

[Seldaek]

@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.

[shama]

@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.

[shama]

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.

[uzyn]

@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.

1. Firstly, there will no longer be a point for specifying type as it is simply ignored if installer-paths is present. composer/installers would then risk to become simply a hack for Composer for specifying custom installation directories.
2. Secondly, should, say CakePHP 2.3 moves the Plugin dir to be within Vendor (ie. Plugin/Vendor/{$name}), a package that uses installer-paths would gain no such automatic update even if composer/installers are updated with the proper path.
   (It's a separate discussion altogether on whether composer/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.

[shama]

#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.

[robocoder]

What if the name permitted a regex with named parameters? e.g.,

    "Plugins/{$shortName}": ["(?:cakephp-)(?P<shortName>.*)"]

[shama]

@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!