On May 24, 2011, at 10:51 PM, Cosimo Streppone wrote:
> If you had to maintain patches, do you apply the patches
> to all your projects lpan/ and dlib/ folders?
[Sorry for the fragmented response. I'm a bit scatter-brained at this hour]
Locally patched modules are an interesting case. You co
On May 24, 2011, at 10:51 PM, Cosimo Streppone wrote:
> When you start a second project that uses a subset
> of project1 dependencies, what do you do?
We should probably clarify what we mean by "project" and "application".
I think of an application as all the code that will run against a partic
Hi,
On Wed, May 25, 2011 at 7:03 AM, Jeffrey Thalhammer
wrote:
>
> On May 24, 2011, at 10:51 PM, Cosimo Streppone wrote:
>
>> When you start a second project that uses a subset
>> of project1 dependencies, what do you do?
>>
>> Do you duplicate the lpan/ and dlib/ folders?
>> If you had to mainta
On May 24, 2011, at 10:51 PM, Cosimo Streppone wrote:
> When you start a second project that uses a subset
> of project1 dependencies, what do you do?
>
> Do you duplicate the lpan/ and dlib/ folders?
> If you had to maintain patches, do you apply the patches
> to all your projects lpan/ and dli
On Wed, 25 May 2011 15:19:49 +1000, Jeffrey Thalhammer
wrote:
On May 24, 2011, at 1:17 PM, David Golden wrote:
Then, given one of those three ordered list of tarballs that satisfy
all prereqs, it should be possibly to repeatably deploy an application
with a known set of module versions, eve
On May 24, 2011, at 1:17 PM, David Golden wrote:
> Then, given one of those three ordered list of tarballs that satisfy
> all prereqs, it should be possibly to repeatably deploy an application
> with a known set of module versions, even as the "latest" on CPAN
> evolves.
.
Wow! This is getting
On Tue, May 24, 2011 at 5:27 PM, Jan Dubois wrote:
> AFAICT there is no good index for backpan though. I have to audit diffs
> to older module versions quite often, so I have my own tools, and found
> that even the links are not comprehensive; I have to crawl both
> backpan/modules/by-module and
On Tue, 24 May 2011, David Golden wrote:
>
> On Tue, May 24, 2011 at 4:32 PM, Leon Timmermans wrote:
> > On Tue, May 24, 2011 at 10:17 PM, David Golden wrote:
> >> Then, given one of those three ordered list of tarballs that satisfy
> >> all prereqs, it should be possibly to repeatably deploy an
On Tue, May 24, 2011 at 4:32 PM, Leon Timmermans wrote:
> On Tue, May 24, 2011 at 10:17 PM, David Golden wrote:
>> Then, given one of those three ordered list of tarballs that satisfy
>> all prereqs, it should be possibly to repeatably deploy an application
>> with a known set of module versions,
On Tue, May 24, 2011 at 10:17 PM, David Golden wrote:
> Then, given one of those three ordered list of tarballs that satisfy
> all prereqs, it should be possibly to repeatably deploy an application
> with a known set of module versions, even as the "latest" on CPAN
> evolves.
That could get a bit
On Tue, May 24, 2011 at 12:25 PM, David E. Wheeler wrote:
> Well, are you using the same version ranges spec for the META.json file?
> Seems to me that this might result in a stand-alone library that, given
> prereqs, could determine what should be installed. Then the existing clients
> could u
On May 24, 2011, at 9:18 AM, David Golden wrote:
> I doubt it. I have plans for an "application installer" that will
> pre-compute dependencies and reliably set up per-application lib
> directories. Different applications could have different versions of
> a module, but a single application will
On Tue, May 24, 2011 at 12:14 PM, David E. Wheeler wrote:
> On May 24, 2011, at 3:04 AM, David Golden wrote:
>
>>> Or, if Net::Ping on the system is already 2.36
>>> it will refuse to proceed?
>>
>> I think the current CPAN clients will all refuse to proceed. This is
>> what I meant when I said t
On May 24, 2011, at 3:04 AM, David Golden wrote:
>> Or, if Net::Ping on the system is already 2.36
>> it will refuse to proceed?
>
> I think the current CPAN clients will all refuse to proceed. This is
> what I meant when I said that version ranges don't accomplish the goal
> because the compute
On Mon, May 23, 2011 at 11:52:39AM -0700, Jeffrey Thalhammer wrote:
> After looking at David Wheeler's PGXN and David Cantrell's CPAN snapshots,
> I've come up with a story. Tell me if you think this makes sense (or not):
>
> Historically, CPAN mirrors have always been static files. In other w
On Mon, May 23, 2011 at 8:38 PM, Cosimo Streppone wrote:
> I say:
>
> "prereqs" : {
> ...
> "runtime" : {
> "requires" : {
> "Net::Ping" : "<= 2.35"
> }
> },
> ...
> },
>
> Where current Net::Ping on CPAN is 2.36,
> than this will install Net::Pin
On Monday, May 23, 2011, David Golden wrote:
> The problem is that there is no way for a single application to use multiple
> versions of a module. So it's easy to imagine that very specific module
> prereqs could be in conflict and require manual override. That's not the
> right answer.
>
> W
On Tue, 24 May 2011 07:22:02 +1000, David E. Wheeler
wrote:
On May 20, 2011, at 11:04 AM, Jeffrey Thalhammer wrote:
[1] I think a lot of this trouble would go away if the CPAN tool chain
simply permitted authors to express precisely which $VERSION of
something they require.
Hi David,
The problem is that there is no way for a single application to use multiple
versions of a module. So it's easy to imagine that very specific module
prereqs could be in conflict and require manual override. That's not the
right answer.
What we need is application level dependencies that are speci
19 matches
Mail list logo
