Deal with version issues in the ecosystem

[JJ]

Right now, zef takes whatever is in the URL pointed to by source-url, as far as I can tell. Distributions are not forced to release via tags, or to announce those releases via META.list. Besides, we don't check for changes in META6.json.
There should be a way of announcing or saying which version is the official. Just adding a version number that should correspond to a tag (and to the version in META6.json) should be enough. Besides, now "version squatting" is possible: just release a new distribution with a later version, and the ecosystem will get yours.
I am kind of aiming at CPANTS, but not only. A sweep and test of all distros would be nice, but as far as I can tell, this is what zef does; that's good and well, but it's not within the ecosystem, or available to the general public (or to other possible dependencies management tools)

[tbrowder]

And I strongly suggest we get rid of the old ecosystem entirely, which is what the original goal was I thought. We should not count anything not on CPAN as "official." Too many modules listed in modules.org don't have test results shown, and too many are not actively supported. [rant completed]

And another thing: the system should use Hjson for the META6.json tests so silly, but common, errors like an extra comma on the last items in lists will not cause failure (a warning msg would be okay, though).

[JJ]

The problem with CPAN is that it's got its own problems. Modules there are not even tested for META6.json correctness, not to mention run actual tests. I'd like to have the best of both worlds. Maybe suggest that as a Google Summer of Code project?

[Scimon]

I think we should keep the Ecosystem functionality as well for a slightly different reason. Even if we ditch the original Ecosystem for OS modules it's a perfect system for internal company modules. This is something I think it would be good to be able to easily support in the future.

[JJ]

El mié., 27 feb. 2019 a las 14:33, Simon Proctor (<notifications@github.com>) escribió:

I think we should keep the Ecosystem functionality as well for a slightly different reason. Even if we ditch the original Ecosystem for OS modules it's a perfect system for internal company modules. This is something I think it would be good to be able to easily support in the future.

You mean create a company-version by changing some stuff in zef? Because right now I don't think there's anything resembling that in the ecosystem...

[Scimon]

I was investigating this. And the current setup for Ecosystem (Big JSON file of META6.json data) pointing the git repos would be very easy to manage internally with build pipelines.

Then looking at Zef it has a config system with a set of plugins for different possibilties (local cache, Cpan, Ecosystem and a disabled metacpan option). So it should be a case of adding a second Ecosystem plugin to your config that gives the details for your internal Meta Meta Json file.

I was going to talk about this tomorrow but hadn't manage to test all my hypotheses yet to see if it worked the way I expected.