develooper Front page | perl.perl5.porters | Postings from March 2022

Whither MANIFEST?

Thread Next
From:
demerphq
Date:
March 9, 2022 17:12
Subject:
Whither MANIFEST?
Message ID:
CANgJU+WqoQV-Hn=k9+t+A=-R+dPsRX2OcJumBctPkbip6L-5Fw@mail.gmail.com
What is the purpose of MANIFEST?

In https://github.com/Perl/perl5/issues/19511
and https://github.com/Perl/perl5/issues/19512

Nicolas R. and I are discussing what we "ship", the fact that we
specifically exclude certain files, and various other issues.

Nicolas seems to think that not listing a file in MANIFEST means it
won't "ship". I am not sure about that, if it does do so then it does
it inconsistently. Perlbrew fetches its code for blead from:

https://github.com/Perl/perl5/archive/blead.tar.gz

and the tarball includes files that are not in MANIFEST.

The latest release 5.34 does not include .git*, nor .mailmap but does
include .travis.yml

All of the files in Porting/ *are* listed in MANIFEST and are included
in the both tarballs.

So I guess that MANIFEST *does* specify what goes into the production
release tarball.

In Porting/manicheck we have:

        return if $_ eq '.mailmap';
        return if $_ eq '.gitignore';
        return if $_ eq '.gitattributes';
        return if $_ eq '.git_patch';

excluding various files. Shouldn't .travis.yml be excluded? Why do we
include it in a production release tarball?

This all seems a little inconsistent, and a little scattered. For
instance, why do we include Porting/checkAUTHORS.pl and
Porting/bisect.pl but we do not include .mailmap or the files above?
Where would we put descriptions of the files that we skip that I
showed above?

This feels icky. It seems like we should have MANIFEST and
MANIFEST.porting or something to separate the files that ship and the
files that are just for porting and dev purposes. I dont like the idea
of dropping files from MANIFEST and having hard coded exclusions lists
like the above. It seems to me it would be much better if we have
MANIFEST.porting, or maybe Porting/MANIFEST and then list the files
that we do expect to exist in the git repo but do not expect to "ship"
there. Then it would be clear what we should do with a  new "helper"
script that only makes sense if you are in the repo.

Should a tool like checkAUTHORS.pl that really only makes sense if you
have access to git be included in the production release? Should
bisect.pl?

Shouldn't this be a little better structured and more clear?

Yves


-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About