composer / composer

Dependency Manager for PHP
https://getcomposer.org/
MIT License
28.58k stars 4.55k forks source link

Allow multiple types for a package #5187

Closed soullivaneuh closed 8 years ago

soullivaneuh commented 8 years ago

Add the ability to have multiple types for a package.

Concrete case with this project: https://github.com/Soullivaneuh/IsoCodesValidator

This is a library by default. But it also introduces an optional Symfony bundle implement.

So it should be a symfony-bundle type too and should be find via Packagist finder.

I could work on it on both Packagist and composer projects.

curry684 commented 8 years ago

Isn't the real problem that you're fitting multiple purposes in a single package and the bundle part should be a separate thin package using the main library?

Compare https://github.com/doctrine/DoctrineBundle

alcohol commented 8 years ago

I concur with @curry684. A bundle simply offers easy integration with symfony for your library. It should not be a part of the library itself. That defeats the whole purpose.

soullivaneuh commented 8 years ago

In my case, Symfony integration is just two classes with 10 lines of code: https://github.com/Soullivaneuh/IsoCodesValidator/tree/master/src/Bundle

So @curry684, I'm returning your question: Isn't a real problem that I have to create a special bundle for that? IHMO I think yes.

BTW, I created one package like this before: https://github.com/Soullivaneuh/SLLHIsoCodesValidatorBundle

I closed it because too much maintaining work for not a lot of things.

In addition, what if we want to provide multiple integration of a single service? Take example of this one: https://github.com/maknz/slack

It provide a standalone library and a Laravel integration. This integration is just a wrapper and it could be easy to add another ones... And this is not the only one project like this I seen on GitHub.

@alcohol any chance to reopen this issue? I really think it could be a place for a debate.

Seldaek commented 8 years ago

I don't think we can allow multiple types. The installer selection is based on the type, and that's pretty much the sole purpose of types right now.

I see your point that having a separate package per framework is a bit overdone for such a simple library, but that has nothing to do with the type though. People can just as well install your package as a library and use the bundle classes.

If the problem is discoverability, maybe add a symfony-bundle keyword?

greg0ire commented 8 years ago

The installer selection is based on the type, and that's pretty much the sole purpose of types right now.

In the case of symfony2, does it even matter though ? I see there isn't an installer for symfony2 in this list

soullivaneuh commented 8 years ago

@Seldaek Thanks for your answer.

I don't think we can allow multiple types. The installer selection is based on the type, and that's pretty much the sole purpose of types right now.

I see. So why not a secondary-type or something else?

I see your point that having a separate package per framework is a bit overdone for such a simple library, but that has nothing to do with the type though. People can just as well install your package as a library and use the bundle classes.

This is the purpose of this kind of project, yes. :+1:

If the problem is discoverability, maybe add a symfony-bundle keyword?

Already done: https://packagist.org/packages/sllh/iso-codes-validator

But this is not the problem, if someone do a search like this: https://packagist.org/search/?q=iso-codes&type=symfony-bundle

The corresponding package will never be shown. This why I'm suggesting the multiple type or, at least a secondary-type (that will be included on Packagist search engine when using type argument).

stof commented 8 years ago

In the case of symfony2, does it even matter though ? I see there isn't an installer for symfony2 in this list

There isn't because Symfony 2 does not impose a special installation path for bundles. It just wants them to be autoloadable. And so we let the default composer installer being used.

stof commented 8 years ago

@Soullivaneuh the issue may be the fact that we have type-based search on Packagist, pushing people to abuse the type for something else than its composer meaning.

soullivaneuh commented 8 years ago

@Soullivaneuh the issue may be the fact that we have type-based search on Packagist, pushing people to abuse the type for something else than its composer meaning.

Yes and no IMO. I understand people using type for search because it's more accurate than tags. For example, which tag for Symfony? #Symfony? #Symfony2? #Symfony3?