develooper Front page | perl.perl6.users | Postings from October 2017

module ecosystem and cpan6 and consistency

Thread Next
Richard Hainsworth
October 17, 2017 03:29
module ecosystem and cpan6 and consistency
Message ID:
When panda was first introduced as the first module or package manager, 
a file containing the meta information for all the modules, located at 
"" 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 

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 

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.


Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About