Re: Should MANIFEST go in the repository?
On Wed, Aug 20, 2008 at 12:57 PM, David Golden [EMAIL PROTECTED] wrote: Anyway. I am in the Keep MANIFEST in repo and manually update camp. Me, too, usually. Me three. -- Shawn Boyette [EMAIL PROTECTED]
Should MANIFEST go in the repository?
Hi everyone- At my current $job, the Perl code is organized into a handful of cpan- style distros. We use Module::Build to build each distro, and then use CPAN.pm to orchestrate the deployment of the application from a local CPAN repository. This all works like a charm. But there is some debate about whether the MANIFEST and other metafiles should be put in the source code repository. My gut feeling is that MANIFEST is a generated file, therefore it does not go in the repository. Instead, the MANIFEST.SKIP file should be carefully crafted to ensure that the MANIFEST is correct. However, this raises a question: How do you ensure that *unexpected* cruft files don't end up in the MANIFEST? My colleagues prefer to have the MANIFEST file in the repository so they can run distcheck to see what's been added or removed before committing some work. And then they manually edit MANIFEST or just run ./Build manifest whenever MANIFEST gets out of sync. But we frequently forget to do this and it results in build failures in our continuous integration system. In my own distros (Perl-Critic), non of the metafiles are in the repository. I only worry about the MANIFEST when I'm about to actually make a dist. We have Module::Build wired up so that the test target depends on the manifest target. The implication is that we would always run tests before making a dist. And only then do I really look inside the MANIFEST. If something seems amiss, then I add a line to MANIFEST.SKIP or do whatever is necessary at that point. I don't run continuous integration on Perl-Critic, but I feel this has worked well. At least I'm never bothered with spurious warnings about my MANIFEST being out of sync. So what are the best practices for managing distro metafiles (MANIFEST in particular)? Jeffrey Thalhammer Imaginative Software Systems vcard: http://www.imaginative-software.com/contact/jeff.vcf
Re: Should MANIFEST go in the repository?
First of all thanks for Perl::Critic! I am quite sure this question has the potential of a nice holy war. Anyway. I am in the Keep MANIFEST in repo and manually update camp. I think MANIFEST is and should be the tool you control what gets in the distro and the failures and warnings you might get during continuous integration are just the way to err, warn you about forgetting something. Gabor
Re: Should MANIFEST go in the repository?
On Wed, Aug 20, 2008 at 12:50 PM, Gabor Szabo [EMAIL PROTECTED] wrote: I am quite sure this question has the potential of a nice holy war. Likewise. Anyway. I am in the Keep MANIFEST in repo and manually update camp. Me, too, usually. I like to have the repository tag for a release contain exactly the files in the tarball on CPAN. This includes things like META.yml. David
Re: Should MANIFEST go in the repository?
On Aug 20, 2008, at 09:57, David Golden wrote: Anyway. I am in the Keep MANIFEST in repo and manually update camp. Me, too, usually. I like to have the repository tag for a release contain exactly the files in the tarball on CPAN. This includes things like META.yml. +1, although I recently stopped including META.yml, I always want to have MANIFEST in the repo. Best, David
Re: Should MANIFEST go in the repository?
# from David E. Wheeler # on Wednesday 20 August 2008 10:39: +1, although I recently stopped including META.yml, I always want to have MANIFEST in the repo. Same here. The reason, for me, is that generating META.yml is almost always predictable but generating MANIFEST very often reveals that something should have been done to MANIFEST.SKIP. There is the caveat that regenerating needs to be done consistently. For instance, `rm MANIFEST` and `MANIFEST` yield different results (and of course you *must* empty or delete the file before ./Build manifest to pickup on the fact that a file was removed.) The MANIFEST provided by Module::Starter also doesn't match the generated order, comments, etc. But once you get through all of that, you can see a nice diff whenever you change it ;-) --Eric -- But you can never get 3n from n, ever, and if you think you can, please email me the stock ticker of your company so I can short it. --Joel Spolsky --- http://scratchcomputing.com ---
Re: Should MANIFEST go in the repository?
On Wed, Aug 20, 2008 at 1:53 PM, Eric Wilhelm [EMAIL PROTECTED] wrote: The reason, for me, is that generating META.yml is almost always predictable My view: * META.yml is an evolving spec * The build tools are periodically updated to produce the latest current spec * Storing META.yml in the repository has almost zero marginal cost[1] -- David [1] assuming sufficient automation of the release process
Re: Should MANIFEST go in the repository?
* Jeffrey Thalhammer [EMAIL PROTECTED] [2008-08-20T12:42:49] But there is some debate about whether the MANIFEST and other metafiles should be put in the source code repository. My gut feeling is that MANIFEST is a generated file, therefore it does not go in the repository. Instead, the MANIFEST.SKIP file should be carefully crafted to ensure that the MANIFEST is correct. However, this raises a question: How do you ensure that *unexpected* cruft files don't end up in the MANIFEST? I don't store MANIFEST, I store MANIFEST.SKIP. In fact, on my latest dists, I only include the MANIFEST as a couresty to stupid software that expects it. I don't see any value in having a MANIFEST file in the dist, let alone in my repo. I have other tools for managing what ends up in the tarball; I configure those instead of MANIFEST, which I find to be a fairly anemic tool. -- rjbs
Re: Should MANIFEST go in the repository?
On Wed, Aug 20, 2008 at 02:56:45PM -0400, Ricardo SIGNES wrote:
In fact, on my latest dists, I only include the MANIFEST as a couresty to
stupid software that expects it. I don't see any value in having a MANIFEST
file in the dist, let alone in my repo.
My .zshrc includes the following lines:
mf() { perl -MExtUtils::Manifest=maniread -le 'print for sort keys
%{maniread()}' }
tg() { tcgrep -brun $@ }
mg() { tg $@ `mf | perl -lne 'print if -T'` }
This allows me to say something like
$ mg -iw bodge
to find all occurrences of bodge in the original distribution, which I
have found to be quite helpful.
I also keep my MANIFEST under revision control. It annoys me to do so,
and I suspect that a good 5% of my checkins are along the lines of
update MANIFEST, but I don't yet trust myself not to mess things up if
I don't check it in. This, of course, says more about me than it does
about what should be considered best practice.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: Should MANIFEST go in the repository?
* Jeffrey Thalhammer [EMAIL PROTECTED] [2008-08-20 18:45]: My colleagues prefer to have the MANIFEST file in the repository so they can run distcheck to see what's been added or removed before committing some work. Err. Shouldn’t that be your VCS’s job? Every single one I’ve used has a `status` command that tells me what I’ve touched, and in my experience it is be much more reliable than `MANIFEST`. So is this discussion in your workplace actually a tooling issue? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Should MANIFEST go in the repository?
Jeffrey Thalhammer wrote: At my current $job, the Perl code is organized into a handful of cpan-style distros. We use Module::Build to build each distro, and then use CPAN.pm to orchestrate the deployment of the application from a local CPAN repository. This all works like a charm. But there is some debate about whether the MANIFEST and other metafiles should be put in the source code repository. My gut feeling is that MANIFEST is a generated file, therefore it does not go in the repository. Instead, the MANIFEST.SKIP file should be carefully crafted to ensure that the MANIFEST is correct. However, this raises a question: How do you ensure that *unexpected* cruft files don't end up in the MANIFEST? This seems to be a subset of the should the repository contain all the release files? argument. Should the repo contain just the files which build a release, or should they contain all the files that go into a release? One side would argue that everything should be in version control so you can track down bugs. The other side argues that keeping generated files up to date is annoying. The pragmatic answer to this question depends largely on your release process and how much stuff you generate. My colleagues prefer to have the MANIFEST file in the repository so they can run distcheck to see what's been added or removed before committing some work. And then they manually edit MANIFEST or just run ./Build manifest whenever MANIFEST gets out of sync. But we frequently forget to do this and it results in build failures in our continuous integration system. Regardless of whether it's checked in, you should not be updating MANIFEST by hand. It's rote work better done by the monkeys inside your computer. Keep a properly maintained MANIFEST.SKIP and generate MANIFEST. Also, there is a disttest target which will simulate testing a distribution by copying all the files in MANIFEST to a subdir and run tests in that. I run it as part of my release process. -- Look at me talking when there's science to do. When I look out there it makes me glad I'm not you. I've experiments to be run. There is research to be done On the people who are still alive. -- Jonathan Coulton, Still Alive
Re: Should MANIFEST go in the repository?
* Michael G Schwern [EMAIL PROTECTED] [2008-08-20 23:05]: This seems to be a subset of the should the repository contain all the release files? argument. Should the repo contain just the files which build a release, or should they contain all the files that go into a release? One side would argue that everything should be in version control so you can track down bugs. The other side argues that keeping generated files up to date is annoying. The pragmatic answer to this question depends largely on your release process and how much stuff you generate. Idle musing: if you have a sufficiently able VCS, couldn’t you have it both ways? Keep a main branch that contains just the essentials, and for a release merge it over to the release branch where the generated files are then refreshed and also checked back in. No? I can’t currently think of any reason for which this would fail, although I might be missing something obvious. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Should MANIFEST go in the repository?
* Michael G Schwern [EMAIL PROTECTED] [2008-08-21 01:50]: is it worth the administrative effort The administrative effort of all of three commands? (Switch branch then merge, plus check in – with the usual release procedure being performed inbetween, prior to check-in.) just to keep trunk clean of one generated file? As I indicated by “idle musing,” I was thinking in general terms about the keep-everything vs ignore-generated debate. If it’s only `MANIFEST`, the overhead of that particular approach is wasted, no doubt. It also presumes that the generated files aren't of any use to day to day development. No it doesn’t, each branch can keep a different list in `.fooignore`. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
