Re: Is the CPAN river always a DAG?
>
> * Can CPAN be cyclic?
>
There are likely classes of circular dependencies that exist, but are
invisible from the metadata.
"the river" is not conclusive, just an aspect that helps us reason
about significance.
For instance, there is plenty of code all over perl that does:
if ( eval "require Foo" ) {
Foo->stuff
} else {
Other->stuff()
}
Such a construct implies a conditional, weak dependency on Foo, but is
frequently not exposed in the metadata.
This means that if Foo is present but functionally broken, the
consumer ( and all its consumers ) will by proxy be broken.
But this is entirely invisible on the river, due in part to the lack
of describing data in the metadata.
Techniques like this are frequently employed to side-step technical
problems that occur when a circular dependency would prevent
installation.
Subsequently, when reasoning about the river, consider it "a minimal
subset of useful information that can help guide decisions", but not
by any means all the information, and you must make conjectures that
the reality is *worse* than the river describes.
--
Kent
KENTNL - https://metacpan.org/author/KENTNL
Re: Is the CPAN river always a DAG?
On Tue, Mar 27, 2018 at 3:17 PM, James E Keenan wrote: > A few weeks ago I made a presentation to the Philadelphia Perlmongers > (http://thenceforward.net/perl/talks/phlpm20180312/index.html) on the > subject "Testing CPAN against the Perl 5 Core Distribution: Where Do We > Stand?". In that presentation, I sketched the concept of the CPAN river and > described it as a directed acyclic graph (DAG) > (http://thenceforward.net/perl/talks/phlpm20180312/slide017.html), using one > of Neil Bower's images to make that point. > > In the discussion afterwards, a prominent former COBOL programmer suggested > that there was nothing to exclude the possibility of circular dependencies > among CPAN distributions. A could depend on B, which depends on C, which > depends on A. If so, we would have a cyclic graph. Wouldn't that undermine > the concept of the CPAN river, he asked. > > Since all I know about DAGs I got from reading Wikipedia and the > documentation to Jarkko's Graph.pm module, I didn't have a good response. > So I promised to ask the question here. > > * Can CPAN be cyclic? > > * If so, then does that mean that, when we speak of CPAN as a river, we are > *imposing* DAG-ness on it by means of the algorithm(s) with which we > calculate the river (e.g., https://github.com/dagolden/zzz-index-cpan-meta)? There have been cases of circular dependencies in the past, though no CPAN client will handle them nicely anyway so they should iron out by themselves. I don't think it undermines the concept of the river, though it probably does complicate the calculation. Leon
Re: Is the CPAN river always a DAG?
On Tue, 27 Mar 2018, James E Keenan wrote: Date: Tue, 27 Mar 2018 15:17:59 +0200 From: James E Keenan To: [email protected] Subject: Is the CPAN river always a DAG? A few weeks ago I made a presentation to the Philadelphia Perlmongers (http://thenceforward.net/perl/talks/phlpm20180312/index.html) on the subject "Testing CPAN against the Perl 5 Core Distribution: Where Do We Stand?". In that presentation, I sketched the concept of the CPAN river and described it as a directed acyclic graph (DAG) (http://thenceforward.net/perl/talks/phlpm20180312/slide017.html), using one of Neil Bower's images to make that point. In the discussion afterwards, a prominent former COBOL programmer suggested that there was nothing to exclude the possibility of circular dependencies among CPAN distributions. A could depend on B, which depends on C, which depends on A. If so, we would have a cyclic graph. Wouldn't that undermine the concept of the CPAN river, he asked. Since all I know about DAGs I got from reading Wikipedia and the documentation to Jarkko's Graph.pm module, I didn't have a good response. So I promised to ask the question here. * Can CPAN be cyclic? Yes ; considered as a graph, CPAN has points (modules), and links from point A to point B iff A uses B. Given a set of modules, any graph is possible. It is not hard to find a cycles, if (at least one) exists ; but if you find a cycle, it is (a priori) not clear how to break it. * If so, then does that mean that, when we speak of CPAN as a river, we are *imposing* DAG-ness on it by means of the algorithm(s) with which we calculate the river (e.g., https://github.com/dagolden/zzz-index-cpan-meta)? You can always make a DAG of CPAN, by leaving out links (dependencies) or points (modules). It is not so easy to find a minimal set of links to leave out. Jim Keenan Regards, Henk Penning _ Henk P. Penning, ICT-beta R Uithof MG-403_/ \_ Faculty of Science, Utrecht UniversityT +31 30 253 4106 / \_/ \ Leuvenlaan 4, 3584CE Utrecht, NL F +31 30 253 4553 \_/ \_/ http://www.staff.science.uu.nl/~penni101/ M [email protected] \_/
Re: Is the CPAN river always a DAG?
On 03/27/2018 02:17 PM, James E Keenan wrote: A few weeks ago I made a presentation to the Philadelphia Perlmongers (http://thenceforward.net/perl/talks/phlpm20180312/index.html) on the subject "Testing CPAN against the Perl 5 Core Distribution: Where Do We Stand?". In that presentation, I sketched the concept of the CPAN river and described it as a directed acyclic graph (DAG) (http://thenceforward.net/perl/talks/phlpm20180312/slide017.html), using one of Neil Bower's images to make that point. In the discussion afterwards, a prominent former COBOL programmer suggested that there was nothing to exclude the possibility of circular dependencies among CPAN distributions. A could depend on B, which depends on C, which depends on A. If so, we would have a cyclic graph. Wouldn't that undermine the concept of the CPAN river, he asked. Since all I know about DAGs I got from reading Wikipedia and the documentation to Jarkko's Graph.pm module, I didn't have a good response. So I promised to ask the question here. * Can CPAN be cyclic? * If so, then does that mean that, when we speak of CPAN as a river, we are *imposing* DAG-ness on it by means of the algorithm(s) with which we calculate the river (e.g., https://github.com/dagolden/zzz-index-cpan-meta)? As I see it, we can't have a non DAG where all dependent modules are non Perl-core modules. Or it would be impossible to install (ask cpan to install A, it will download B, then C, then try again to install A). Nevertheless, we can have A1 that depends on B that depends on A2, where A2 exists as a core Perl module, older version than A1. Thus, B would be happy to build based on the previous, older, version, and then A1 use B. I think I got some similar situation some years ago, but I can't refer whose modules they were. Hope this can help, ambs
