Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Custom install paths for package name #2

Closed
derhasi opened this issue Jan 12, 2015 · 2 comments · Fixed by #6
Closed

Custom install paths for package name #2

derhasi opened this issue Jan 12, 2015 · 2 comments · Fixed by #6

Comments

@derhasi
Copy link
Contributor

derhasi commented Jan 12, 2015

Composer installers allows custom paths for package names. I think this is very useful, especially if you have not control of the package to implement and you do not want to rely on the composer type of the package. Therefore I'd propose to switch to the same syntax as Composer Installers.

{
    "extra": {
        "custom-installer": {
            "web/": ["type:drupal/core"],
            "web/sites/{$name}/": ["type:drupal-site"],
            "custom/{$type}/{$vendor}/{$name}/": ["type:random-type"],
            "libraries/{$vendor}/{$name}": ["somevendor/somename"]
        }
    }
}

Is this something you are interested in? As so, I'd try to create a PR for that.

@davidbarratt
Copy link
Owner

There's actually already a project like that:
https://github.com/mnsami/composer-custom-directory-installer

Does that fit your needs?

@derhasi
Copy link
Contributor Author

derhasi commented Jan 12, 2015

Not really, as it lacks the replacement patterns. Sure that would not be necessary, as we have a specific name. But with the Composer Installers syntax you can provide multiple packages for a single path pattern. This would be a better experience from my perspective.

In addition it feels some kind of odd to me, to use separate installers for quite the same task. I'd very much would like to see one go-to-solution for custom paths, instead of splitting up the core code to separate installers in separate versions and separate reasons of why thinks do not work.

I would have loved to see that custom approach in composer/installers, but they explicitly do no not want that.

So I thought your installer would be a great starting point for that. If you would not like that, I'd try to fork composer/installers for that custom purpose :)

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants