> And this presumes that the person running the install knows enough to > "consider." Which is fine if you're coding Perl. Not so obvious if you are > trying to use someone else's package, which may silently fall back to > crippled mode "because it's better than nothing".
Nowhere in the distribution install process requires a user to read and understand Perl. All they need to do is invoke their cpan client. If more work is needed than that, the author has made an error. > As an author, I want to be able to specify what I need without writing Perl that invalidates the tools that sort out dependencies. That's what the prereq specification is for in META.json. For most distributions, this is perfectly adequate, and static analysis tools can consume this data and generate dependency graphs and other nice things. However, for the things where dynamic configuration is needed, often *nothing else will do but running Perl code on the target system.* JSON-MaybeXS's prereqs cannot be declared in any other way than in Perl, and that Perl has to run on the target system. We simply cannot say in advance what prereqs will be needed by a particular installation until we try to install it. > The user tools (cpan, cpanm) can't answer the question "If I want this > package, what would I need/install?" without actually installing in the real > environment. That's not true at all. You can run 'perl Makefile.PL' manually in the target environment to generate a MYMETA.json and see what the final list of prereqs are. That's not the full list of recursive dependencies, true, but it's conceivable that cpanm could run the configure phase of the next layer of dependencies, to get *their* dependencies, and so on -- this is not perfect, as configure-phase dependencies *must* be installed before we can go further, and some distributions' configure phases may behave differently depending on what is already installed (JSON-MaybeXS is an example of this -- what dependencies you get depends on what JSON backends you already have installed, and at what versions.) > I hate to disagree with Karen, but the swamp really is a bad as I think - > once you understand that your audience isn't just people who know what the > Camel book is, much less read it. It's also people with other priorities, > and tools for those people. If you have a particular usecase or problem in mind, let's discuss it (although cpan-workers is a better list for that than here). Otherwise, declaring that the current tools are inadequate, without specifying what the problems are, is totally unhelpful and seems to me to be spreading FUD. On Wed, Nov 9, 2016 at 4:52 PM, Timothe Litt <tlhack...@cpan.org> wrote: > On 09-Nov-16 19:11, Dan Book wrote: > > On Wed, Nov 9, 2016 at 9:49 AM, Timothe Litt <tlhack...@cpan.org> wrote: >> >> cpan and cpanm seem to handle 'recommended' differently. IIRC, neither >> defaults to installing 'recommended' modules. >> > > Sadly, this is correct and in fact (as far as I know) CPAN.pm still > handles recommended prereqs completely wrongly if you do enable them (fails > the installation if they don't install). cpanm handles them more correctly > but still not ideally. The fact they are not installed by default, in turn, > makes them not any more useful than 'suggests' in practicality, so it ends > up being a semantic difference. 'recommends' should be modules which are > always a good idea to install but not required, and 'suggests' should be > modules which the user may consider installing if they choose. > > And this presumes that the person running the install knows enough to > "consider." Which is fine if you're coding Perl. Not so obvious if you > are trying to use someone else's package, which may silently fall back to > crippled mode "because it's better than nothing". I see this all the time > with a package I distribute, where people who install it can't spell P u r > l. Oh, there's an 'e'? I've had to shell script the mechanics of > bootstrapping that package onto a system that's never seen Perl. > > This leads to the case as you noted with JSON::MaybeXS, where the only > practical solution in the current state of things is to instead rely on > dynamic dependencies, and add a hard dependency on the modules that are > appropriate at installation time. Dynamic dependencies however are a very > widely supported and backwards compatible system. Only configure-time > dependencies are read from the static META.json, the rest are read from the > generated MYMETA.json, generally even if dynamic_config is set to 0, though > in that case it is imperative that the generated prereqs match the static > ones. > > But leaves the original issue unresolvable: MetaCPANdeps can't figure out > what's really required. As Karen noted, once you set the 'dynamic' flag, > all bets are off. > > And as you point out, the user experience is less than ideal. As a user, > all I want is to type "install this_thing_that_I_want", and not worry about > "suggests", "recommends", or any thing else. The baggage ought to come > without effort and excess baggage fees. (I know, retrograde thought.) > > As an author, I want to be able to specify what I need without writing > Perl that invalidates the tools that sort out dependencies. Even if > MetaCPANdeps decided to install every module to see what it *REALLY* > required, it could only know in the tested environment. The user tools > (cpan, cpanm) can't answer the question "If I want this package, what would > I need/install?" without actually installing in the real environment. My > observation that a language is probably required to solve was only partly > tongue in cheek - at least it could let the user tools provide an accurate > answer. MetaCPANdeps could at least provide a symbolic answer - resolving > the symbols for static dependencies, and providing the equation of what's > left with the unresolved symbols. (Pass 2 would make it prettier...) > > I don't claim to have a complete view or solution. But I'm pretty sure > that David's suggestion to toss grandkid (and great-great grand cousin > three times removed?) require/suggest/hope&pray into META is not enough to > make a real dent in the problem. > > I hate to disagree with Karen, but the swamp really is a bad as I think - > once you understand that your audience isn't just people who know what the > Camel book is, much less read it. It's also people with other priorities, > and tools for those people. > > Sigh. > >
