Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"
 
PerlMonks  

Re: Per-distro versioning and dependency specification

by Anonymous Monk
on Jun 06, 2012 at 07:29 UTC ( [id://974668]=note: print w/replies, xml ) Need Help??


in reply to Per-distro versioning and dependency specification

there are numerous distributions (…) for which it would be tedious and error-prone to specify each constituent dependency seperately. The existence of such distributions renders strict per-module dependency specification impractical.

Perl::PrereqScanner makes short work of that.

The only safe assumption for an author to make is that some fraction of the user base has listed the primary module of a distro as a dependency when they really want a different module within the distro.
This looks like some sort of circular argument to me: "I advocate per-distro versioning, and some people already do per-distro versioning, so per-distro versioning should be done generally."

In the majority opinion, when someone does per-distro versioning, it constitutes an accidental bug and should be fixed to become per-module.

leaving all other modules without versions
This only works if the proposal is universally accepted and implemented. (This is already implied from the later section "Recommendations", I rather want to say this explicitly, too.)
  • Comment on Re: Per-distro versioning and dependency specification

Replies are listed 'Best First'.
Re^2: Per-distro versioning and dependency specification
by creamygoodness (Curate) on Jun 06, 2012 at 13:57 UTC

    There is no need for this proposal to be "universally accepted and implemented." :) I merely hope that individual authors will consider it.

    As for exploding dependency lists using Perl::PrereqScanner, I'm agnostic. It might be good defensive programming for downstream users, but I think any upstream author who justifies recomposing a distribution on the basis of Perl::PrereqScanner's availability is irresponsible.

    Ultimately, a version number has to stand for some bounded collection of code. My argument is that it assigning disparate version numbers to subdivisions within a collection of code which can only be installed as a single atomic unit is unhelpful, and thus that version numbers should be unified within such installation units.

    For the sake of argument, why not assign version numbers to individual subroutines? Subroutines can be moved to different distros, too. Is Perl::PrereqScanner paranoid enough? :) Of course the answer is that the Perl 5 interpreter and use/require deal in modules with version numbers -- but there is tension between that and how modules typcially get packaged and installed as indivisible collections.

    Now I might argue that it would be better logical behavior if the interpreter understood the concept of distros and dealt with version numbers at that level -- and that angle interests me as a student of language design and informs my opinions about best practice. However, in this Meditation I have attempted to limit the concrete suggestions to those which can implemented without either

    • a time machine, or
    • the unanimous consent of all CPAN authors.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://974668]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others perusing the Monastery: (7)
As of 2024-04-23 11:47 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found