search

composer / installers

A Multi-Framework Composer Library Installer
MIT License
1.43k stars 412 forks source link

Add wordpress-core type #77

Closed Rarst closed 11 years ago

Rarst commented 11 years ago

WP extensions are already finely supported by installers, but the situation with WP core itself is less smooth. If it is placed in root then it's not subject to Composer, however subdirectory installs (which only recently became supported for all cases) are and probably should be.

However typical subdirectory install for WP is not the same thing as for typical Composer library, because paths matter, are exposed in admin area URLs, etc. In a nutshell putting WordPress core into vendor directory would be atypical and possibly problematic (technically and/or to satisfy requirements of specific projects).

Currently working options:

  1. Declare core to be of wordpress-plugin installer type and customize installer path for it to wordpress (or other desirable path with single level of nesting). Confusingly puts core into plugins directory, if path is not customized.
  2. Declare core to be of fake wordpress-core type. More logically goes into vendor if path is not customized, but non-existent type feels like a hack, I am not sure won't stop working.

Proposal:

Add wordpress-core type with default wordpress path for valid subdirectory install by default without path customization.

shama commented 11 years ago

Please see #38 and #57

Rarst commented 11 years ago

@sham I have read the Drupal ticket before opening this one, however I don't know their specifics enough to follow.

To be clear I am not asking for the files-in-root case here, just to make handling WP core a little more robust with better default case. There are no autoload issues or anything because WordPress core doesn't use autoload.

FuelPHP ticket seems to imply that "core" packages would need additional testing, however in WordPress case I don't see difference between already working plugin/theme types and potential core type.

shama commented 11 years ago

core types would exist for only 1 package where other types exist for many packages. I understand core types seem really useful but they seem problematic to me. As soon as 2 packages use the same core type it is going to blow up. I'm not saying no to core types I'm simply asking if someone really wants them and for me to maintain them... then please include actual package install tests: #43

I'm also reluctant because it seems create-project exists to handle this use case.

Rarst commented 11 years ago

I'm also reluctant because it seems create-project exists to handle this use case.

You mean using WP core as root package? But then you need to edit it and essentially cannot update it...

Anyway I see your concerns about core types from the installers side. Since WP as project is nowhere near using Composer officially, I guess dirty hacks will have to do for private use for developers meanwhile. :)

sbuzonas commented 11 years ago

@Rarst in PR #53 I opted to create a separate installer because it didn't seem to fit the purpose of this project IMO.

Rarst commented 11 years ago

@slbmeh saw that, hadn't tested yet (as above we don't need this to make it work, just need to mess with path customization). It just seems like really tiny code change for WP installer, but drags too many considerations with it as above.