-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support automatic library download via composer dependencies #15
Comments
Big fan of the idea. We have an existing issue ucdavis/sitefarm_seed#170 to do just that. However, I've hit a speed bump with the package naming that happens when pulling the package. For example, the Wordcount plugin for CkEditor gets pulled in with a wrapping directory I'm using "extra": {
"installer-types": [
"bower-asset",
"npm-asset"
],
"installer-paths": {
"docroot/libraries/{$name}": [
"type:bower-asset",
"type:npm-asset"
]
}
} |
ack, so annoying when the package structure doesn't line up! (no, you're not missing anything). We could:
What say you? |
I was hoping to avoid needing scripts, but I think number 3 is probably our best bet. I'd prefer not to fork repos if we can help it, and I'm not sure how feasible/timely number 2 would be. I'm gonna work on an implementation with the script solution in 3. At the very least it would work as a simple stop-gap so that we can at least move this forward. I'm gonna close this issue as a duplicate of ucdavis/sitefarm_seed#170 since we've been trying to keep all issues over in the main profile repo. |
Yeehaw! Sounds good, thanks @mrkmiller. FYI the script portion of the PR will need to go against the distro, 'cause scripts are "root only". |
The SiteFarm profile includes the complete code of seven libraries. Let's figure a way around that. If any of them are available on npm or bower, use asset-packagist to require them. Otherwise, we have a few options. In descending order of preference:
composer.json
and then have the maintainers (or whoever owns the namespace) submit the project to packagist.composer.json
and then submit it to packagist. If you'd like to go this route for any of the libraries, just let me know which ones and I'll take care of it.composer.json
for each library. Note that the repo definition must go in the rootcomposer.json
, i.e., they won't be read from the profile's, unfortunately.Let me know watcha think! Thanks.
The text was updated successfully, but these errors were encountered: