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
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
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
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
# 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
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
# from David Golden
# on Wednesday 20 August 2008 11:27:
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
* 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,
On Wed, Aug 20, 2008 at 2:55 PM, Eric Wilhelm
[EMAIL PROTECTED] wrote:
Umm, is that for or against storing META.yml in the repo? For me, the
cost of checking it in is that you continually have to confront the
regen/diff/commit issues for a file where the differences don't really
mean anything
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
# from David Golden
# on Wednesday 20 August 2008 12:23:
I want it
checked in, particularly since the META.yml in a release is dependent
on the particular EU::MM or M::B I had installed on whatever machine I
happened to be working on at the time I released the code.
Hmm, I guess it depends on
On Wed, Aug 20, 2008 at 4:16 PM, Eric Wilhelm
[EMAIL PROTECTED] wrote:
Hmm, I guess it depends on what you think a tag should contain, along
with some artifacts of the VCS (e.g. a tag must be a copy of trunk
sort of thing.)
For me, the tag *is* the release.
My release tagging program makes
* David Golden [EMAIL PROTECTED] [2008-08-20 22:40]:
My release tagging program makes sure the code is checked in
locally and synchronized to the remote repository, checks that
the MANIFEST is up to date, checks that the release tag matches
the version found in the META.yml, checks that the
* 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
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
* 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
On Wed, Aug 20, 2008 at 4:49 PM, Aristotle Pagaltzis [EMAIL PROTECTED] wrote:
Mind throwing it into some publicly visible spot somewhere so
people can gawk at it? (I'm deliberately not saying release it
since that would imply polishing it to a degree you probably have
no desire for.)
Uh,
# from David Golden
# on Wednesday 20 August 2008 13:37:
I guess it depends on what you think a tag should contain,
along with some artifacts of the VCS (e.g. a tag must be a copy of
trunk sort of thing.)
For me, the tag *is* the release.
So, you delete everything from the tag which matches
On Wed, Aug 20, 2008 at 5:45 PM, Eric Wilhelm
[EMAIL PROTECTED] wrote:
For me, the tag *is* the release.
I meant that metaphorically.
So, you delete everything from the tag which matches MANIFEST.SKIP? My
checkouts tend to contain files which don't go in the release and my
releases contain
# from David Golden
# on Wednesday 20 August 2008 14:26:
Uh, yeah, sure cringe
http://echo.dagolden.com/scratch/
There's a 500 error on the .pl file there.
And it's very specific to the way in which I setup my distributions
and the way in which I've started embedding version numbers into
On Wed, Aug 20, 2008 at 5:58 PM, Eric Wilhelm
[EMAIL PROTECTED] wrote:
There's a 500 error on the .pl file there.
Removed the .pl extension. (sigh)
Of course, by trying to make it abstract and reusable, I'm just making
unnecessary work for myself because every author with more than 3
# from David Golden
# on Wednesday 20 August 2008 14:57:
For me, the tag *is* the release.
I meant that metaphorically.
Yeah, but how metaphorically? If a recursive diff on (e.g.) 'svn export
$tag' and the unpacked tarball produces output, then the tag == the
release.
No, my repository can
# from David Golden
# on Wednesday 20 August 2008 15:10:
Of course, by trying to make it abstract and reusable, I'm just
making unnecessary work for myself because every author with more
than 3 modules writes their own kit? At least, that's the
impression I get whenever I mention it.
David E. Wheeler wrote:
This all built up over years as I tried to automate away each stupid
distribution packaging mistake I've made in releasing something to
CPAN.
This should be a module. I'd use it.
What about foy's Module::Release?
* 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
25 matches
Mail list logo
