Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re: What are the files in a CPAN distribution?

by Corion (Pope)
on Dec 19, 2012 at 16:19 UTC ( #1009590=note: print w/ replies, xml ) Need Help??


in reply to What are the files in a CPAN distribution?

./MANIFEST.SKIP - many authors use this to list the files they have in their development directory which they don't want to package. Most distribution building processes will honour this list. They should really include MANIFEST.SKIP in their MANIFEST.SKIP so that it doesn't get distributed!

I disagree with that point. Not having/knowing the MANIFEST.SKIP can make it highly tedious to rebuild a distribution. I think that the .gitignore and MANIFEST.SKIP and other such ephemeral parts of distribution building should be distributed so that other people can easily rebuild a distribution file if they are running their own inhouse CPAN mirror for example.


Comment on Re: What are the files in a CPAN distribution?
Select or Download Code
Re^2: What are the files in a CPAN distribution?
by tobyink (Abbot) on Dec 19, 2012 at 16:34 UTC

    OK, so you have a MANIFEST.SKIP file which lists "foo.txt". So somebody downloading the tarball knows that foo.txt should be skipped. But they don't have foo.txt, do they? foo.txt was never packaged.

    perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'

      But foo.txt may be generated by the build process or by the tests, and might be machine/environment specific and shouldn't be redistributed.

      My MANIFEST.SKIP files also list files used by source code managment as well as temporary files. These temp files might be generated during testing, running examples, etc. Why hand out additional work to another author if/when (s)he takes over the distribution or wants to put a modified/fixed version into a local darkpan repo?

      "I know what i'm doing! Look, what could possibly go wrong? All i have to pull this lever like so, and then press this button here like ArghhhhhaaAaAAAaaagraaaAAaa!!!"
Re^2: What are the files in a CPAN distribution?
by davido (Archbishop) on Dec 19, 2012 at 19:18 UTC

    I agree with Corion here: I distribute MANIFEST.SKIP and think it's ok to distribute the /xt directory (or author-only tests). It just assures that if someone else wants to work on the module too, they've got everything that I would use if it were me working on it. It's easy enough to ensure that those ./xt tests only run if an environment variable is set, so at worst they're a little extra disk space, and at best they might help another contributor, bug-fixer, etc.


    Dave

      Most modules are no in some sort of reproducable VCS: svn or git, and most have some sort of preferred way of contributions (github).

      If people want to work on a module/distribution, a git clone or svn copy will get you *all* files, including those that - I agree with tobyink here - are listed in .gitignore and MANIFEST.SKIP. I hope at least that the authors are sane enough to have these two in the repository anyway.


      Enjoy, Have FUN! H.Merijn

        I do keep modules in public Git repos, and in the module's POD point to that repo. Nevertheless, when someone looks for a distribution, they look to CPAN, and I try to provide the complete dist there. Anyway, the good thing about Perl is that TIMTOWTDI. :)


        Dave

        We can not rely only on the source repository of the author to get the original source. First, too few authors advertise the place of that repository in their metadata. Then, the author may decide to make it private, or delete it completely. Look at what happened to Marcel Grunauer 200+ modules when he dropped his Github account in August 2011...

        The only reliable archive is the CPAN. This is where the source must be.

        This is why I hate tools that transform the original source : PodWeaver, Dist::Zilla::Plugin::ExtraTests...

      and think it's ok to distribute the /xt directory (or author-only tests)

      I agree. Even if the tests are never run by someone else, they might still prove a valuable resource to another author. And if (somewhat unexpectedly cause my code is always perfect) bug reports start flooding in, it is always a good thing to have all existing tests for the distribution already deployed. It's much easier to ask a user to "just run this command(s) and post the output" than first having to haggle about how to send the test scripts and set up the test environment.

      "I know what i'm doing! Look, what could possibly go wrong? All i have to pull this lever like so, and then press this button here like ArghhhhhaaAaAAAaaagraaaAAaa!!!"
Re^2: What are the files in a CPAN distribution?
by dolmen (Sexton) on Dec 21, 2012 at 13:35 UTC
    Not having/knowing the MANIFEST.SKIP can make it highly tedious to rebuild a distribution.

    +1

    The only Perl archive I trust for the long term is the CPAN. Every distribution should be rebuildable from itself, perl, and other CPAN distros.

    If an author abandons his module, we want to be able to continue his work from the CPAN data, not relying on an other source that may have disappeared with the maintainer.

      My general position on this is that the CPAN distribution is not the development tree; the CPAN distribution is a product of the development tree.

      My repo may contain a bunch of extra files (author tests, Devel::Cover output, benchmarking scripts, etc) which are not included in the distro. And similarly the distribution will contain a bunch of auto-generated files (like META.yml, Changes, LICENSE, etc) that I have no desire to check into my repo.

      However if I go under a bus tomorrow and somebody else needs to pick up the distro, they don't actually need any of that stuff. They could just download the tarball, extract the files, make a few changes, bump the version numbers, and then use tar to create a new tarball, and upload it.

      OK, that might seem like a pain for them not to be able to use the author tests, etc I have in my repo, but actually if you think about it, it makes it easier for them to transition the distribution to their own build tools. They can start working on the distribution the way they like to work on software, not the way I like to work on software. (Especially considering I'm somewhat of an oddball in my development style!)

      perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (8)
As of 2014-07-31 12:26 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (248 votes), past polls