A quick comment on this one, before work begins on implementing it.
This proposal involves the creation of 8+ new dependency types, none
of which have been discussed in detail as far as I can tell.
Pending rigourous analysis of the implications of this proposal, I
think it's fluff. It sounds
Opposed until someone can demonstrate working dependency algorithms
that take this into account.
-1
Adam K
I concur, this is better addressed in a packfile 2.0 process at a later date.
Adam K
On Sun, Nov 1, 2009 at 2:48 AM, David Golden xda...@gmail.com wrote:
On Fri, Oct 9, 2009 at 7:56 AM, David Golden xda...@gmail.com wrote:
33. Install Meta files and make them queryable
Proposal: Using
I'd prefer we avoid pointless flexibility.
Recommend we pick one, and since underscore requires less quoting and
can be used as part of a method name, recommend we go with that.
Adam K
On Sun, Nov 1, 2009 at 7:07 AM, David Golden xda...@gmail.com wrote:
On Mon, Oct 12, 2009 at 10:08 AM, David
Which version of version.pm, it moves.
What happens if it changes slightly in the future.
Adam K
On Tue, Nov 3, 2009 at 12:35 PM, David Golden xda...@gmail.com wrote:
On Mon, Nov 2, 2009 at 7:45 PM, Ricardo Signes
perl.cpanw...@rjbs.manxome.org wrote:
* Adam Kennedy a...@ali.as [2009-11
It's been something of a long-standing (second-order) problem that
packages are just tarballs (or bzipball, or zips, etc).
The lack of a standard file extension means that we can't sanely
implement features like double-click to install on operating systems
and browsers with file extension
I'd rather like to avoid adding additional complexity to the current
index files.
Instead, what about switching to a native SQLite index for the new system.
This is working quite nicely in the JSAN now, and it greatly
simplifies things because you can download the index much more simply.
1.
... or, like JSAN does, all of the above.
We make multiple different formats available, as many as people ask
for pretty much.
As long as they stay in sync, there's no real problems that happen
from encoding the index in N number of ways.
Adam K
On Wed, Jan 6, 2010 at 2:59 PM, Ask Bjørn Hansen
(b) sounds like an interesting idea.
Adam K
On Fri, Feb 19, 2010 at 2:03 AM, David Golden xda...@gmail.com wrote:
On Thu, Feb 18, 2010 at 9:12 AM, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 da...@cpan.org wrote:
I of course ran `perl Makefile.PL ; make ; make testdistro ; make test` on
the
source directory before
What he said.
Most people don't mirror CPAN. They mirror many things.
This is the same reason we've struggled with statistics. How do you
ask someone mirroring three dozen different things to put in a special
log-munging tool just for us.
Adam K
On Fri, Mar 26, 2010 at 10:55 AM, Ask Bjørn
On Fri, Apr 2, 2010 at 4:11 AM, Michael G Schwern schw...@pobox.com wrote:
* The need for widespread mirroring is less significant than it was in
years past. (Also using git as the inter-mirror transport of source files
means there'll be much less traffic between mirrors. Effectively only
the
This has already existed for about a year or more.
See pip's .p5i file (which I think cpanminus also supports).
Adam K
On Fri, Apr 16, 2010 at 12:56 AM, Curtis Jewell
lists.perl.cpan-work...@csjewell.fastmail.us wrote:
Why don't we make the .cpan/.c6pan file (.c6pan) a JSON file, generated
by
I'm pretty sure that's true for all such systems, including things
like .war files.
Even if we split, say, Strawberry from ActivePerl, what if you have
multiple installations of ActivePerl?
Adam K
On Fri, Apr 16, 2010 at 8:56 AM, Jan Dubois j...@activestate.com wrote:
On Thu, 15 Apr 2010,
I was worried that was it. That conversion should be considered,
but not enshrined in the spec as a limit.
999 revisions ought to be enough to anyone
If we can get the MIRROR.yaml|json system I proposed finally deployed,
this rewrite would become trivially easy.
Adam K
On Sun, Sep 26, 2010 at 10:52 PM, Jarkko Hietaniemi j...@iki.fi wrote:
On Sunday-201009-26 8:16, Ask Bjørn Hansen wrote:
On Sep 26, 2010, at 4:49, Jarkko Hietaniemi wrote:
On Mon, Sep 27, 2010 at 12:31 PM, Ask Bjørn Hansen a...@perl.org wrote:
Related notes: would it make sense to sign the (timestamped) list of mirrors?
I added some heuristic anti-hijacking stuff to a previous version of
Mirror::JSON so it would at least provide a basic level of projection.
I think I may have implemented what you're looking for several years
ago for JSAN, which has a client that auto-detected appropriate
mirrors in a few seconds each time it starts.
http://search.cpan.org/~adamk/Mirror-URI-0.90/lib/Mirror/YAML.pm
Or at least, something similar to it.
It
Packlist 2.0
MYMETA + installed file details
?
On Dec 17, 2012 12:36 AM, Tim Bunce tim.bu...@pobox.com wrote:
On Sun, Dec 16, 2012 at 04:53:49PM -0800, Michael G Schwern wrote:
On 2012.12.16 11:57 AM, Leon Timmermans wrote:
* Where to put the database? What about non-standard install
You should probably scan CPAN for other uses of use inc::...
My darker memory is throwing up some other potentially false positive red flags.
File::ShareDir may be worth a look as it did some fairly funky stuff at
build/test time... at one point in its history.
Anything file in CPAN with an
That doesn't help those of us with a habit of naming our test modules
t::Foo::Bar
I think there's a fair few things with copies of test modules bundled that way.
Adam
> On 14 Nov. 2016, at 11:45 am, Karen Etheridge wrote:
>
> > In this case, adding '.' to the distribution's
Nov 2017 at 9:29 pm, Adam Kennedy <a...@ali.as> wrote:
> I have fragments and variations of this stuff tucked away in old code I’m
> sure.
>
> Look at LWP::Online and Test::NeedsDisplay, and I may have done similar
> things in the test suites for ORDB::*
>
> Adam
>
&g
21 matches
Mail list logo