Giters

composer / packagist

Package Repository Website - try https://packagist.com if you need your own -

Home Page:https://packagist.org/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Get "dependents" with specific version constraints

fe-hicking opened this issue · comments

commented

I would love for a possibility on packagist to get a list of packages which depend on a specific version constraint of a base package.

There is i.e. https://packagist.org/packages/typo3/cms-core/dependents?order_by=downloads - but that lists a few thousand packages. I would like to only see packages that are compatible with TYPO3 ^12.0.

Reason is I want to check for a specific code fragment in all public extensions for this project for research, and I somehow need to download&grep in all these packages.

As a fallback I could use a filter option on https://packagist.org/search.json?type=typo3-cms-extension&per_page=100 with version constraints?

(I tried for a few hours to research existing issues and stackoverflow, didn't really find anything. I'm sorry if there is a duplicate issue on this)

commented

Yeah this is not so simple as you'd need to examine really the versions and whether the constraints intersect. E.g. you are interested in ^12 but what about something requiring 12.5.3, or >=11, or ~12.4, all those should be found too.

So this isn't something we can defer to the database, and it's thus way more cpu intensive to query. But yes we maybe could add a filter option.. It'd just maybe need to come with some restrictions on the amount of packages/versions we inspect. For sure looking only at the latest version of each minor release of each dependent would already reduce the dataset, if the original amount is too large.

commented

Thanks for your response! Yes I figured that is harder than it sounds. :-)

For TYPO3 development and most importantly for supporting it, it would be quite awesome if we have such a filter.

For certain features that may get deprecated or where a major bug is found, it would be cool if we could just automatically parse all matching "external" dependents on that package and maybe inform package authors specifically. Or just see, how many dependents use specific functionality that may change.

And developers may easier look up examples for specific versions of a dependency to see how "others do it".

(I've actually went the route and downloaded ALL dependents there, extracted latest releases, do a code-search on it. That might be a pro-feature idea for the private packagist maybe, which touches that)

commented

FYI this is similar to (if not a duplicate of) #1048