Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Issues with VERSION migration in a module suite

7 views
Skip to first unread message

Phillip Moore

unread,
May 30, 2012, 8:04:35 AM5/30/12
to cpan-teste...@perl.org
I just took over one of my older module suites (NetApp.pm, which is
actually about 20 distinct NetApp::* classes), and decided to change
the versioning scheme to match the style I'm using in all the rest of
my code. In the older release, which was written back in 2008, I
used a per-file SVN Revision tag as the VERSION, which led to
per-module versions in the 100s. The version of the distribution was
1.1.2, and I had been using v-strings for versions back in those days.

In all my newer code, I dropped the individual module versions, and I
use a single VERSION for the entire distro. I updated the distro
version to 2.002, but PAUSE did NOT like this file when I uploaded it,
because all of the individual module versions appeared to decrease,
not increase. Now, the 02packages.txt.gz data shows the problem:

NetApp 2.002 W/WP/WPMOORE/NetApp-2.002.tar.gz
NetApp::Aggregate 332.000000 W/WP/WPMOORE/NetApp-1.1.2.tgz
NetApp::Aggregate::Plex 203.000000 W/WP/WPMOORE/NetApp-1.1.2.tgz
NetApp::Aggregate::RAIDGroup 203.000000 W/WP/WPMOORE/NetApp-1.1.2.tgz
NetApp::Filer 410.000000 W/WP/WPMOORE/NetApp-1.1.2.tgz
NetApp::Filer::Export 203.000000 W/WP/WPMOORE/NetApp-1.1.2.tgz
NetApp::Filer::License 203.000000 W/WP/WPMOORE/NetApp-1.1.2.tgz
NetApp::Filer::Option 203.000000 W/WP/WPMOORE/NetApp-1.1.2.tgz
NetApp::Filer::TimeoutCache 334.000000 W/WP/WPMOORE/NetApp-1.1.2.tgz
NetApp::Filer::Version 203.000000 W/WP/WPMOORE/NetApp-1.1.2.tgz
NetApp::Qtree 334.000000 W/WP/WPMOORE/NetApp-1.1.2.tgz
NetApp::Snapmirror 275.000000 W/WP/WPMOORE/NetApp-1.1.2.tgz
NetApp::Snapmirror::Destination 203.000000 W/WP/WPMOORE/NetApp-1.1.2.tgz
NetApp::Snapmirror::Source 203.000000 W/WP/WPMOORE/NetApp-1.1.2.tgz
NetApp::Snapshot 275.000000 W/WP/WPMOORE/NetApp-1.1.2.tgz
NetApp::Snapshot::Delta 203.000000 W/WP/WPMOORE/NetApp-1.1.2.tgz
NetApp::Snapshot::Schedule 203.000000 W/WP/WPMOORE/NetApp-1.1.2.tgz
NetApp::Volume 419.000000 W/WP/WPMOORE/NetApp-1.1.2.tgz
NetApp::Volume::Source 203.000000 W/WP/WPMOORE/NetApp-1.1.2.tgz

There's an obvious solution here: make the distro version something
with a major version greater then 419, and then all of these will
increase, PAUSE will be happy, and I can keep moving forward.

However, is this the only solution? Is there any way to convince
PAUSE that those older module versions didn't matter?

I suspect not, but before I jump from 1.1.2 to 2.002 and then 500.0001
(420.0001 is *very*, very tempting.... :-) I'd like to be sure there's
no other choice.

Dean Hamstead

unread,
May 30, 2012, 9:07:31 AM5/30/12
to cpan-teste...@perl.org
Hopefully version 420 will be stable?

Dean
--
Come play computer games with us at http://fragfest.com.au

David Golden

unread,
May 30, 2012, 9:46:47 AM5/30/12
to Phillip Moore, cpan-teste...@perl.org
On Wed, May 30, 2012 at 8:04 AM, Phillip Moore
<w.phill...@gmail.com> wrote:
> However, is this the only solution?  Is there any way to convince
> PAUSE that those older module versions didn't matter?

No. I'm pretty sure versions have to increase. However, you could
try *deleting* all the modules/distributions from CPAN, waiting until
it clears out of the 02packages file, and then re-uploading with all
2.003 VERSION strings. That might work, or might not, but I don't
think you lose anything other than time by trying it.

Note that people with older versions installed might have trouble
upgrading without a forced installation of a particular distribution.
The most user-friendly thing to do is to bump up to NNN.0001 or
whatever.

-- David

Marvin Humphrey

unread,
May 30, 2012, 10:33:12 AM5/30/12
to David Golden, Phillip Moore, cpan-teste...@perl.org
On Wed, May 30, 2012 at 6:46 AM, David Golden <xda...@gmail.com> wrote:
> On Wed, May 30, 2012 at 8:04 AM, Phillip Moore
> <w.phill...@gmail.com> wrote:
>> However, is this the only solution?  Is there any way to convince
>> PAUSE that those older module versions didn't matter?
>
> No.  I'm pretty sure versions have to increase.  However, you could
> try *deleting* all the modules/distributions from CPAN, waiting until
> it clears out of the 02packages file, and then re-uploading with all
> 2.003 VERSION strings.  That might work, or might not, but I don't
> think you lose anything other than time by trying it.

Does PAUSE ever forget about a file entirely? This implies not:

http://pause.perl.org/pause/query?ACTION=pause_04about#upload

For security reasons you will never be able to upload a file with
identical name again.

> Note that people with older versions installed might have trouble
> upgrading without a forced installation of a particular distribution.
> The most user-friendly thing to do is to bump up to NNN.0001 or
> whatever.

I really wish that versions and dependencies were expressed at the distro
level rather than the module/package level. Allowing multiple version numbers
within an atomic unit of installation doesn't make sense.

I agree that the best way to handle things to derive a single version number
which is at least `max(@versions) + $n` and use that for all modules. It
might look a little weird, but oh well -- it's justified from an engineering
standpoint. At least unifying the version numbers produces a sane outcome,
albeit at the expense of violating DRY.

Marvin Humphrey

David Golden

unread,
May 30, 2012, 10:40:25 AM5/30/12
to Marvin Humphrey, Phillip Moore, cpan-teste...@perl.org
On Wed, May 30, 2012 at 10:33 AM, Marvin Humphrey
<mar...@rectangular.com> wrote:
> Does PAUSE ever forget about a file entirely?  This implies not:
>
>    http://pause.perl.org/pause/query?ACTION=pause_04about#upload
>
>    For security reasons you will never be able to upload a file with
>    identical name again.

You can't upload the same *tarball*, but that's not what I suggested.

> I really wish that versions and dependencies were expressed at the distro
> level rather than the module/package level.  Allowing multiple version numbers
> within an atomic unit of installation doesn't make sense.

I agree. Now all we need is a DeLorean, a flux capacitor and 1.21 gigawatts.

> I agree that the best way to handle things to derive a single version number
> which is at least `max(@versions) + $n` and use that for all modules.  It
> might look a little weird, but oh well -- it's justified from an engineering
> standpoint.  At least unifying the version numbers produces a sane outcome,
> albeit at the expense of violating DRY.

I outline the concept of a well-formed distribution here:
http://www.dagolden.com/index.php/308/packages-modules-and-distributions/

I would go further and say that I recommend that whenever possible,
all modules in a distribution should have the same version number, to
avoid the sort of distro/module version sync problems that people have
experienced.

-- David

Marvin Humphrey

unread,
May 30, 2012, 11:05:29 AM5/30/12
to David Golden, Phillip Moore, cpan-teste...@perl.org
On Wed, May 30, 2012 at 7:40 AM, David Golden <xda...@gmail.com> wrote:

>> I really wish that versions and dependencies were expressed at the distro
>> level rather than the module/package level.  Allowing multiple version numbers
>> within an atomic unit of installation doesn't make sense.
>
> I agree.  Now all we need is a DeLorean, a flux capacitor and 1.21 gigawatts.

*chuckle*

It's possible to overlay a package management system on top of Perl5/CPAN
which uses distro-level dependency specification. I don't know the gory
details, but isn't that what apt-get, rpm, etc do?

It would also be easy for a build system to enforce unified versions at distro
build time. It's not possible to prevent tarballs from appearing on CPAN
which violate this provision, but the issue is not so hopeless or insoluble
that we try to understand the problem better.

> I outline the concept of a well-formed distribution here:
> http://www.dagolden.com/index.php/308/packages-modules-and-distributions/
>
> I would go further and say that I recommend that whenever possible,
> all modules in a distribution should have the same version number, to
> avoid the sort of distro/module version sync problems that people have
> experienced.

+1

Marvin Humphrey

Phillip Moore

unread,
May 30, 2012, 2:38:53 PM5/30/12
to cpan-teste...@perl.org
Meant to reply-all, but....

---------- Forwarded message ----------
From: Phillip Moore <w.phill...@gmail.com>
Date: Wed, May 30, 2012 at 2:38 PM
Subject: Re: Issues with VERSION migration in a module suite
To: Marvin Humphrey <mar...@rectangular.com>


On Wed, May 30, 2012 at 11:05 AM, Marvin Humphrey
<mar...@rectangular.com> wrote:
> On Wed, May 30, 2012 at 7:40 AM, David Golden <xda...@gmail.com> wrote:
>
>>> I really wish that versions and dependencies were expressed at the distro
>>> level rather than the module/package level.  Allowing multiple version numbers
>>> within an atomic unit of installation doesn't make sense.
>>
>> I agree.  Now all we need is a DeLorean, a flux capacitor and 1.21 gigawatts.
>
> *chuckle*
>
> It's possible to overlay a package management system on top of Perl5/CPAN
> which uses distro-level dependency specification.  I don't know the gory
> details, but isn't that what apt-get, rpm, etc do?

Funny you mention that -- that is *precisely* how my own package
management system for perl works :-P


> It would also be easy for a build system to enforce unified versions at distro
> build time.  It's not possible to prevent tarballs from appearing on CPAN
> which violate this provision, but the issue is not so hopeless or insoluble
> that we try to understand the problem better.
>
>> I outline the concept of a well-formed distribution here:
>> http://www.dagolden.com/index.php/308/packages-modules-and-distributions/
>>
>> I would go further and say that I recommend that whenever possible,
>> all modules in a distribution should have the same version number, to
>> avoid the sort of distro/module version sync problems that people have
>> experienced.

And the irony is that I am trying to *convert* this distro to the very
convention(s) that David recommended.

Deleting the distro and waiting might let me get away with fooling
PAUSE, but someone, somewhere will get burned by the individual module
versions decrementing, so...

Major version 500 it will be.

Thanks for verifying my sanity, or lack thereof....

Steffen Schwigon

unread,
Jun 1, 2012, 8:23:52 AM6/1/12
to David Golden, Phillip Moore, cpan-teste...@perl.org
David Golden <xda...@gmail.com> writes:
> On Wed, May 30, 2012 at 8:04 AM, Phillip Moore
> <w.phill...@gmail.com> wrote:
>> However, is this the only solution? Is there any way to convince
>> PAUSE that those older module versions didn't matter?
>
> No. I'm pretty sure versions have to increase. However, you could
> try *deleting* all the modules/distributions from CPAN, waiting until
> it clears out of the 02packages file, and then re-uploading with all
> 2.003 VERSION strings. That might work, or might not, but I don't
> think you lose anything other than time by trying it.

Just to clarify on that 'might work': Yes, it works, but you definitely
need to wait until it was deleted (~2 days). Otherwise you might need to
explicitely reindex those lower numbers in PAUSE.


> Note that people with older versions installed might have trouble
> upgrading without a forced installation of a particular distribution.
> The most user-friendly thing to do is to bump up to NNN.0001 or
> whatever.

Increasing it will also avoid oneself's own confusion once you hit again
those large version number you deleted and forgot about in the meantime
and are forbidden to upload the same version number several years in the
future again.

Kind regards,
Steffen
--
Steffen Schwigon <s...@renormalist.net>
Dresden Perl Mongers <http://dresden-pm.org/>

Steffen Schwigon

unread,
Jun 1, 2012, 8:24:12 AM6/1/12
to Marvin Humphrey, David Golden, Phillip Moore, cpan-teste...@perl.org
Marvin Humphrey <mar...@rectangular.com> writes:
> On Wed, May 30, 2012 at 7:40 AM, David Golden <xda...@gmail.com> wrote:
>
>>> I really wish that versions and dependencies were expressed at the distro
>>> level rather than the module/package level. Allowing multiple version numbers
>>> within an atomic unit of installation doesn't make sense.
>>
>> I agree. Now all we need is a DeLorean, a flux capacitor and 1.21
>> gigawatts.
>
> *chuckle*
>
> It's possible to overlay a package management system on top of
> Perl5/CPAN which uses distro-level dependency specification. I don't
> know the gory details, but isn't that what apt-get, rpm, etc do?

It is. And it *only* is about the details. And gory. And the "who". Not
the band nor the Dr. but the "who will do and maintain it". So we are
back to David Golden's proposal involving 1.21 gigawatt. :-)

Marvin Humphrey

unread,
Jun 1, 2012, 12:47:49 PM6/1/12
to Steffen Schwigon, David Golden, Phillip Moore, cpan-teste...@perl.org
On Fri, Jun 1, 2012 at 5:24 AM, Steffen Schwigon <s...@renormalist.net> wrote:
> Marvin Humphrey <mar...@rectangular.com> writes:
>> On Wed, May 30, 2012 at 7:40 AM, David Golden <xda...@gmail.com> wrote:
>>
>>>> I really wish that versions and dependencies were expressed at the distro
>>>> level rather than the module/package level. Allowing multiple version numbers
>>>> within an atomic unit of installation doesn't make sense.
>>>
>>> I agree. Now all we need is a DeLorean, a flux capacitor and 1.21
>>> gigawatts.
>>
>> *chuckle*
>>
>> It's possible to overlay a package management system on top of
>> Perl5/CPAN which uses distro-level dependency specification.  I don't
>> know the gory details, but isn't that what apt-get, rpm, etc do?
>
> It is. And it *only* is about the details. And gory. And the "who". Not
> the band nor the Dr. but the "who will do and maintain it". So we are
> back to David Golden's proposal involving 1.21 gigawatt. :-)

It appears that during the 1990s and early 2000s, Perl module developers had
less of an appreciation than we do today for the problems caused by implicit
exports. Fast forward to the present, and common practice has evolved --
few new modules uploaded to CPAN pollute namespaces by default.

For backwards compatibility reasons, most of the problematic modules (e.g.
POSIX) cannot be changed. Yet we have still found ways to benefit from the
hard-won experiences of those module authors and their users.

I hope that future users may benefit from the experiences of authors like
Phillip on the subject of distro-vs-package/module-level versioning. That
starts with us developing a thorough understanding of the problem, and perhaps
developing consensus around best practice.

In that vein, I would like to know: do you, as someone who has spent time in
the trenches working with packaging, believe that version numbers and
dependencies are best expressed at the distro level or at the package/module
level?

It seems to me that the primary benefit to expressing versioning at the
package/module level is that because CPAN.pm only reads versions embedded in
actual source files, it can never fall out of sync -- as opposed to packaging
systems which maintain an external registry that can have incomplete data when
an alternative installation mechanism has been used.

Some might argue that it is also beneficial to be able to express dependencies
in terms of individual modules rather than distros, but the problem there is
that you may not want an implicit upgrade of the *other* modules within the
distro.

(FWIW, I'm currently collaborating with a couple other people on a system
which has some versioning and packaging functionality -- it's not for Perl
modules per se, but the lessons of CPAN are relevant and this thread has been
useful. Neverthless, I'm also interested in this topic strictly as a CPAN
author. It would have been nice if the Lucy community could have avoided
the time-consuming troubleshooting we had to go through.)

Marvin Humphrey

David Golden

unread,
Jun 1, 2012, 4:28:07 PM6/1/12
to Marvin Humphrey, Steffen Schwigon, Phillip Moore, cpan-teste...@perl.org
On Fri, Jun 1, 2012 at 12:47 PM, Marvin Humphrey <mar...@rectangular.com> wrote:
> In that vein, I would like to know: do you, as someone who has spent time in
> the trenches working with packaging, believe that version numbers and
> dependencies are best expressed at the distro level or at the package/module
> level?

It depends.

There are benefits to module-level dependency specification that I can see:

(a) they reflect that *actual* run-time dependency -- a .pm file that
is loaded via require/use (which means the .pm file can migrate to a
differently named distribution and dependency resolution still works)

(b) dependencies can be expressed/enforced in code via "use Foo 1.23"
or "Foo->VERSION(1.23)"

Thus, they map really well to what the interpreter actually needs to
know, whereas distribution-level dependencies have to be managed
entirely outside the interpreter with metadata and packaging tools.

-- David

Steffen Schwigon

unread,
Jun 1, 2012, 5:39:18 PM6/1/12
to Marvin Humphrey, David Golden, Phillip Moore, cpan-teste...@perl.org
Marvin Humphrey <mar...@rectangular.com> writes:
> In that vein, I would like to know: do you, as someone who has spent
> time in the trenches working with packaging, believe that version
> numbers and dependencies are best expressed at the distro level or at
> the package/module level?

It will be a different answer for each CPAN author
and in Perl this individualism is our collectivism.

Elliot Shank

unread,
Jun 1, 2012, 11:03:32 PM6/1/12
to David E. Wheeler, Steffen Schwigon, Marvin Humphrey, David Golden, Phillip Moore, cpan-teste...@perl.org
On 6/1/12 9:49 PM, David E. Wheeler wrote:
> On Jun 1, 2012, at 2:39 PM, Steffen Schwigon wrote:
>>> In that vein, I would like to know: do you, as someone who has spent
>>> time in the trenches working with packaging, believe that version
>>> numbers and dependencies are best expressed at the distro level or at
>>> the package/module level?
>>
>> It will be a different answer for each CPAN author
>> and in Perl this individualism is our collectivism.
>
> No it won’t, and no it isn’t.

I agree with Mr. Wheeler.

As someone who's split modules out of a distribution before and someone who's dealing with Ruby gems a lot currently, I'd say that the dependency-on-a-distro model is broken. Perl's dependency-on-a-module model is the correct one. When the contents of a distro change, dependency-on-a-module continues to work, whereas a dependency-on-a-distro does not.

Phillip Moore

unread,
Jun 2, 2012, 11:36:26 AM6/2/12
to cpan-teste...@perl.org
Coffee is still kicking in -- forgot to Reply-All and share this with
the list.....

---------- Forwarded message ----------
From: Phillip Moore <w.phill...@gmail.com>
Date: Sat, Jun 2, 2012 at 11:35 AM
Subject: Re: Issues with VERSION migration in a module suite
To: Elliot Shank <pe...@galumph.com>


I disagree -- you have to deal with both dependencies on modules and
distributions.    Both types of dependency serve slightly different
purposes.

For example, internally in perl you will specify a dependency on a
specific version of a specific module:

use Foo::Bar 1.0;

But, when Foo::Bar is part of a *suite* of modules, which you can't
install independent of the distribution, then you have to think about
depending on the distribution, perhaps Foo-2.1.tar.gz.

I came at this problem from a very, very different angle.  I have
developed a very large scale system for managing arbitrary releases of
software in a common, versionized namespace, and developed a set of
configurable tools for automating the entire installation and
deployment process.  That software is agnostic with respect to the
language or build system used to install the distribution in question,
and I factored out a common framework for doing this.   I have support
for GNU configure, perl's build systems (Build.PL and Makefile.PL),
python and ruby packages, etc.   This system specifies it's
dependencies on the distributions, because it's the distribution that
is quantum of a software release.    IOW, you don't install modules,
you install distributions.   The same is true for things like C
dependencies.   GNU gcc depends libgmp and libmpfr, but in order to
automate the installation process, I need to know that it depends on
gmp-x.y.z.tar.gz and mpfr-a.b.x.tar.gz.

Furthermore, CPAN dependencies are specified at the distribution
level.  META.yml (and it's variants) are all distribution specific
files, however the dependencies they specify are on individual
modules.   To integrate perl with my infrastructure I convert the
module dependencies into a set of distribution dependencies, and then
automate the installation (and the *really* hard and fun part: runtime
dependence management) into my namespace.

The point is that the two different kinds of dependencies serve very
different purposes.  I need to know what distributions something
depends on in order to install them, since the installation process is
per-distribution, but I need to know what modules I depend on, and
perhaps what minimal version I need, in order to manage API
dependencies.

To say we need one or the other misses this fact -- you need both.

Now, it sure would be nice if people could standardize on the
convention that ALL of the modules in a given distribution share the
same version number, but we can't even get people to upload
META.yml/json files consistently.  One of the things I have to do to
make my system work is post-process the minicpan updates and make sure
that I have a metadata file for ALL of the distros possible.  I don't
have recent statistics (I should really log this...) but last time I
did a cursory check a few months ago, nobly about 90-95% of the
modules being uploaded included a metadata file.   With the trend to
depend on MYMETA files, which are unfortunately only generated during
the build process and are not available in the downloaded tar ball,
this percentage may very well decrease.

THAT point being: if you are developing a system to manage arbitrary
CPAN modules, you can't depend on people following *any* guidelines,
and you have to take a heuristic approach and handle a lot of ugly
edge conditions.

Steffen Schwigon

unread,
Jun 2, 2012, 5:49:15 PM6/2/12
to Elliot Shank, David E. Wheeler, Marvin Humphrey, David Golden, Phillip Moore, cpan-teste...@perl.org
I probably misunderstood the question. Bummer!

Marvin Humphrey

unread,
Jun 2, 2012, 11:48:01 PM6/2/12
to Phillip Moore, cpan-teste...@perl.org
Hi Phillip,

The two of us seem to have arrived at very similar positions.

On Sat, Jun 2, 2012 at 8:36 AM, Phillip Moore <w.phill...@gmail.com> wrote:
> For example, internally in perl you will specify a dependency on a
> specific version of a specific module:
>
> use Foo::Bar 1.0;
>
> But, when Foo::Bar is part of a *suite* of modules, which you can't
> install independent of the distribution, then you have to think about
> depending on the distribution, perhaps Foo-2.1.tar.gz.

My "favorite" example is URI::Escape 3.31, which is distributed with
URI-1.60.tar.gz.

http://search.cpan.org/~gaas/URI-1.60/

> Now, it sure would be nice if people could standardize on the
> convention that ALL of the modules in a given distribution share the
> same version number, but we can't even get people to upload
> META.yml/json files consistently.

If each package has a version number and they are all sync'd to the same
number as the distro, that is functionally equivalent to per-distro versioning
and dependency specification, no?

Imagine a system where per-distro metadata files get installed alongside
module files in @INC, where module files contain embedded pointers to their
per-distro metadata file, and where per-distro metadata is used to validate
runtime dependency versioning specification.

I can't think of a situation where those two systems gives us different
results unless a file gets clobbered somewhere.

> THAT point being: if you are developing a system to manage arbitrary
> CPAN modules, you can't depend on people following *any* guidelines,
> and you have to take a heuristic approach and handle a lot of ugly
> edge conditions.

It's true that relying on individual authors is folly, but the people who
write and maintain toolchain modules are more sophisticated -- and they are
the ones who create the boilerplate and the infrastructure that other authors
rely upon.

It's worth building consensus about best practices for the indirect benefit of
less conscientious module authors by way of toolchain authors, as well as for
the direct benefit of conscientious module authors.

Marvin Humphrey

Marvin Humphrey

unread,
Jun 2, 2012, 11:53:15 PM6/2/12
to cpan-teste...@perl.org
Hello Elliot,

Thanks for the thoughtful dissent. :)

On Fri, Jun 1, 2012 at 8:03 PM, Elliot Shank <pe...@galumph.com> wrote:
> When the contents of a distro change, dependency-on-a-module continues to
> work, whereas a dependency-on-a-distro does not.

The thing is, removing a module from a distro generally means breaking
backwards compatibility.

It may be possible to avoid the compat break if a module gets spun off into
a new distro which gets added to the dependency chain of the original, but
under most other circumstances simply removing a module is going to cause
problems for at least some subset of users -- and therefore it should only be
done when the consequences of breaking back compat have been weighed and
deemed acceptable.

You can take a hard line and say that your users must always use per-module
specification because you reserve the right to change the composition of a
distro at any time, but there's no way to validate their dependency specs and
guarantee that they did so. Some of them are going to get screwed.

Mandatory per-module dependency specification is conceptully flawed in any
case simply due to existence of distros with very large numbers of modules.
If you depend on a big suite like Moose, Catalyst::Runtime or Lucy, should you
be required to specify each class from them that you use? That's going to be
tedious and error prone. (Are you *sure* that you listed every last module
that you need?)

But then if you relax the requirements and allow per-distro dependency
specification for big suites, where do you draw the line and start requiring
per-module dependency spec for distros that insist on the freedom to drop a
module at any moment?

Marvin Humphrey

Marvin Humphrey

unread,
Jun 3, 2012, 12:24:35 AM6/3/12
to cpan-teste...@perl.org
On Fri, Jun 1, 2012 at 11:32 AM, David E. Wheeler <da...@justatheory.com> wrote:
> On Jun 1, 2012, at 9:47 AM, Marvin Humphrey wrote:
>
>> (FWIW, I'm currently collaborating with a couple other people on a system
>> which has some versioning and packaging functionality -- it's not for Perl
>> modules per se, but the lessons of CPAN are relevant and this thread has been
>> useful.  Neverthless, I'm also interested in this topic strictly as a CPAN
>> author.  It would have been nice if the Lucy community could have avoided
>> the time-consuming troubleshooting we had to go through.)
>
> You know I wrote something like this, right?
>
>  http://pgxn.org/

For sure! And since you are a fellow Apache Lucy developer, you may have
recognized the system I referenced as Clownfish[1].

PGXN and Clownfish are both off-topic for cpan-testers-discuss, except that
perhaps in this case it might be nice to hear about any experiences with PGXN
and distro-vs-sub-distro dependency specification that would help us to
understand the design tradeoffs better, and ultimately to develop best
practice guidelines for CPAN authors and users. Got anything for us?

Marvin Humphrey

[1] Clownfish is an OO toolkit for C that's currently developed as part
of Apache Lucy; its defining characteristic is the symbiotic relationship
it maintains with a "host" dynamic language such as Perl, Ruby, or Python.
Some Lucy devs would like to spin Clownfish off as a separate project.

Serguei Trouchelle

unread,
Jun 3, 2012, 12:34:22 AM6/3/12
to cpan-teste...@perl.org
Guys, are you sure it's not a "module-authors" topic?
I don't see any relation to CPAN testers here.

--
S.T.

Marvin Humphrey

unread,
Jun 3, 2012, 11:07:13 PM6/3/12
to Serguei Trouchelle, cpan-teste...@perl.org
On Sat, Jun 2, 2012 at 9:34 PM, Serguei Trouchelle <st...@cpan.org> wrote:
> Guys, are you sure it's not a "module-authors" topic?
> I don't see any relation to CPAN testers here.

Rats, I suppose you're right. :(

I was trying to make sure that we didn't lose sight of the original issue and
veer off-topic, but on review the original issue isn't a CPAN Testers problem
-- it's a PAUSE problem!

I don't feel like we're done, but I'm game to take the discussion elsewhere --
probably perlmonks.org.

Thanks to all who have participated -- it's been edifying!

Marvin Humphrey

David Cantrell

unread,
Jun 6, 2012, 9:31:53 AM6/6/12
to cpan-teste...@perl.org
On Sat, Jun 02, 2012 at 08:53:15PM -0700, Marvin Humphrey wrote:

> The thing is, removing a module from a distro generally means breaking
> backwards compatibility.
> ...
> Mandatory per-module dependency specification is conceptully flawed in any
> case simply due to existence of distros with very large numbers of modules.
> If you depend on a big suite like Moose, Catalyst::Runtime or Lucy, should you
> be required to specify each class from them that you use?

Yes, and *only* the ones that you use.

If your code says 'use Some::Module', then declare it as a prerequisite.
But you don't care what Some::Module uses. You should be able to rely
on whatever distribution it is that contains Some/Module.pm to DTRT.

--
David Cantrell | top google result for "topless karaoke murders"

All praise the Sun God
For He is a Fun God
Ra Ra Ra!
0 new messages