search

composer / packagist

Package Repository Website - try https://packagist.com if you need your own -
https://packagist.org/
MIT License
1.76k stars 476 forks source link

Which composer package types are allowed and recommended on Packagist? #714

Closed helhum closed 8 years ago

helhum commented 8 years ago

This is rather an organisational not a technical issue.

The composer documentation states the following:

Separate ecosystem: If you have a project which has its own ecosystem, and the packages aren't really reusable by the greater PHP community, you might want to keep them separate to packagist. An example of this would be wordpress plugins.

My question now is, if this statement is still valid and whether e.g. TYPO3 is considered a "separate ecosystem"

I would argue that a TYPO3 extension (which is only usable with typo3/cms package) can be considered to have the same level of reusability than a symfony bundle (which is more or less only usable with Symfony full stack). A symfony bundle cannot be reused in Laravel projects or Slim Framework projects or TYPO3 projects. Still I consider them to be OK to be hosted on Packagist and a lot of them are already.

Besides that, the goal in the further development of TYPO3 is to better integrate into the general PHP / Composer / Packagist ecosystem. This has been started with TYPO3 7 LTS, which requires a whole lot of libraries, that are hosted on Packagist. And as far as I understood the plans for the future is that TYPO3 will also contribute re-usable libraries and is working towards fully embracing composer as the only dependency and package management tool.

I'm looking forward to hear your opinion on that topic.

rdohms commented 8 years ago

If all framework packages leave Composer, it would lose a lot of its "usefulness". So I believe they should all be included, the biggest difference would be "form of consumption".

Its hard to draw a line with Wordpress plugins as well, I believe they are not really different then bundles or extensions, but their "documented" and supported way of install is not "via composer" but via their own plugin system. For this reason I would think the ideal scenario is that the "worpress plugin shell" requires a composer package that just has regular PHP code. Might even make it more useful so it can be reused in other places.

Swader commented 8 years ago

I think it's fine as it is, include everything, but by god include some basic filtering / searching other than the one that's there now. Filters needed:

Filters should also be saved to be default when a user comes back, OR custom filter strings should be able to be set as new home pages, as in something like Zendesk.

Basically, Packagist is perfectly fine hosting everything it's hosting now and more, but a better UI is sorely needed. No more of this fulltext nonsense, give us faceted search with detailed controls, and watch one of the most powerful package managers out there achieve new glory.

Crell commented 8 years ago

I concur. If a package is public and under a Free Software license, having a dependency on a particular framework isn't an issue. However, having an easier way to filter them out (so that I can search for a generic package that does Foo, and not get the 47 foo-bridge packages for every framework under the sun that I'm not using) would be very welcome.

Side note: Drupal uses its own endpoint/index for Drupal modules, but that's not for standoff-ish reasons. It's more because our existing versioning scheme is not Packagist-compatible, so we have a separate endpoint for each major Drupal version ourselves. That makes the resulting version numbers logically fit into Composer's resolution logic. It's working well so far but is not something I'd recommend for others unless they also have a specific incompatibility, and their own software management infrastructure like Drupal does.

Lefaux commented 8 years ago

We would love to help build a better search (any maybe solve some performance related issues as well in the same process). Filtering (aka "finding what you want) is an UI/API issue and easy to solved (heck, I built my own packagist mirror in elasticsearch for that). The main question is: how many packages can packagist handle? Not just today, but in the next 5 years. So let's crunch some numbers together, just add up what you know now and try to give a prediction for the future. TYPO3: 6k packages, rising. Drupal? Wordpress? Joomla? ModX? Concrete5? Magento? Laravel? Simfony?

Please bear with me, I'm 110% sure I missed A LOT of projects here, just added those that came to memory. If "all" projects add their numbers, we might get a total sum and a prediction how many packages we need to be able to handle, filter etc.

NamelessCoder commented 8 years ago

The expected number for TYPO3 is not 6,000 but significantly lower. According to http://www.t3packagist.org/ there are currently 388 packages of type typo3-cms-extension plus those belonging to TYPO3 itself. I'd estimate the actual number to be somewhere around 5-600 currently maintained extensions are likely to hit packagist (internal note for TYPO3 readers: we would definitely not want to simply copy everything that is on TER to packagist; given the incredibly large amount of unmaintained work therein).

I wholeheartedly second the idea of improving packagist's filtering capabilities as well as designing a more consistent tagging approach with the same goal in mind.

Lefaux commented 8 years ago

@NamelessCoder you underestimate the fact that currently composer (and thus packagist) is optional. Once we'd make it mandatory, I'm convinced the number will be higher than 600.

NamelessCoder commented 8 years ago

@wmdbMattes I am aware of that, sure. We could find out though - we could pull a list of unique extensions updated since 2000-something as a hint to how many existing ones we've got as well as a hint about the frequency of new ones being added. My point is we shouldn't be counting ones updated 2+ years or so ago, nor should we be counting every TER extension as potential packagist release.

We don't want to make ourselves look like messy care-nots who might cause several thousand long unused packages to be recorded!

EDIT: to not turn this into a TYPO3 discussion I think we should come up with an estimate like mentioned and then add that as our expectation - let me know if I can assist with that!

helhum commented 8 years ago

Here are some real numbers:

Number of packages on:

So yes, packages from other ecosystems will add up to Packagist. But currently this additional load will be limited.

But I agree. With or without packages from other ecosystems. Packagist will need to scale within the next years.

I currently just don't see an alternative to a central package name repository.

The package information needs to be both centralized (names can only exist once) and distributed (located in different locations to be able to scale). A bit like the DNS infrastructure.

Seldaek commented 8 years ago

I pretty much agree with most of the discussion here. Having everything on packagist on principle is fine by me, and I think we'll have to manage scaling up either way, as @helhum said it's not 10K more or less packages, it's the bigger picture that matters.

I don't mind though if ecosystems like Drupal have their Drupal-specific packages on their own repo, because it doesn't really hurt anyone else, and it actually helps scaling a bit because the size of the Drupal ecosystem is kinda huge.

Not sure if there is anything else to be said here or if we should close?

Lefaux commented 8 years ago

thanks for the update. Is there anything we can do to help with scaling? Like financial resources, getting servers in, sponsor a devteam for x days?

Seldaek commented 8 years ago

Right now not really no but thanks :)

helhum commented 8 years ago

@Seldaek Thanks a lot for sharing your view on this topic. It gives us planning reliability for our further plans. From my PoV this ticket can be closed.

Thanks to everybody participating in this discussion.