When panda was first introduced as the first module or package manager,
a file containing the meta information for all the modules, located at
"http://ecosystem-api.p6c.org/projects.json"; was established.
At the time, the developers said that the meta information file was
designed to be agnostic of the package manager.
Consequently, it was possible to study the ecosystem of modules by
analysing the meta information. I did this with a module citation index
to see which modules were important for the system. The most interesting
result was how JSON::Tiny was replaced over time by JSON::Fast. This is
actually quite useful for a new developer who wants to know what is the
most popular implementation without having to investigate all modules in
depth.
To be clear, a file containing the meta information about modules is not
the same as specifying where the modules should or should not be located.
Effectively, an Ecosystem began to develop for modules, and the
ecosystem is agnostic of location or package manager.
Some time ago cpan6 came on line an began encouraging developers to move
modules to cpan6.
But it turned out that cpan6 requires another module meta file, (located
at
https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/cpan.json)
I discovered that that the two lists appear to be different, with
JSON::Fast moving off "projects.json" onto 'cpan.json'. This of course
broke my ModuleCitation system.
So, in order to modify the ModuleCitation system, I wanted to know how
to find the different lists, and whether there would be some
transparency about the whole ecosystem.
There was a discussion on IRC perl6, but it was between only three
participants and there did not seem to be any attempt to discuss the issue.
It seems to me for the health and development of the perl6 module
ecosystem that everyone should be able to find out where all the perl6
modules are located and to get their meta data.
Not all modules will be public, but that is a decision to be made by the
developers. Not all the modules will be located in the same location or
accessed in the same way, eg. on cpan6 or on a git repository. But the
meta data contains all this information.
It seems to me that a single canonical list kept by the perl6 community
would be the best option. If in the future, it becomes necessary for
health tests to be performed on the modules, for example, to detect
viruses, malware, or the like, then the community can itself decide.
By community, I mean the way in which perl6 itself is developed. It is
not a free for all, but it is not restrictive. It is simply an effort
with coordination.
It is also possible for there to be multiple files containing meta
information, but at the very least, there should be some public place
where all the lists are themselves listed - a sort of meta meta list.
What seems to be the case at the present is that there are two lists,
which a privileged number of perl6 gurus know about, but information
which is not generally available. There is no coordination between the
lists - that I am aware of.
What is to prevent a situation in which the meta data in each list gets
out of sync in some way? It is not unreasonable to presume that this
could lead to incompatible dependencies being created.
finanalyst.
- module ecosystem and cpan6 and consistency Richard Hainsworth
-
