Nov 2017 at 9:29 pm, Adam Kennedy 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
>
> On Sun, 12 Nov 2017
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
On Sun, 12 Nov 2017 at 7:00 am, James E Keenan wrote:
> Is there any code which is considered "best
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 Makefile.PL made n
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 exp
You could try collecting up a bunch of these different metrics and then run a
regression analysis against the graph wise recursive downstream dep count for
everything on CPAN and see which metrics fall out in the real world.
So many times we come up with arbitrary scoring systems that don't actu
An aside, GetFolderPath() can result in a UNC path return, which might
complicate things about more if you use it.
Note the _d I had to use in File::HomeDir.
http://cpansearch.perl.org/src/ADAMK/File-HomeDir-1.00/lib/File/HomeDir/Windows.pm
Adam
On Thu, May 21, 2015 at 12:37 PM, Jan Dubois wro
I'll say it a second time...
Packlist 2.0
Take MYMETA, add an extra key with the list that will be installed, intall
it in the usual place as we do now.
Package manager scans the filesystem for the packlist files.
Might seem slow, but on SSDs scanning the filesystem like that is super
super fas
Packlist 2.0
MYMETA + installed file details
?
On Dec 17, 2012 12:36 AM, "Tim Bunce" 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
> location
It makes a bigger difference for minicpan than for cpan itself.
But "fast enough" is important, and that fast enough be network relative.
Adam K
On Fri, Apr 29, 2011 at 8:57 PM, Ask Bjørn Hansen wrote:
>
> On Apr 28, 2011, at 9:19, brian d foy wrote:
>
>>> I think I may have implemented what yo
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 autodetects
On Mon, Sep 27, 2010 at 12:31 PM, Ask Bjørn Hansen 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.
Basically, if it s
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 wrote:
> On Sunday-201009-26 8:16, Ask Bjørn Hansen wrote:
>>
>> On Sep 26, 2010, at 4:49, Jarkko Hietaniemi wrote:
>>
>>> I
>>> 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"
Other than stuff that predates our ability to force the toolchain
modules to be updated, obviously...
Adam K
On Mon, Apr 19, 2010 at 11:50 PM, Michael G Schwern wrote:
> David Golden wrote:
>>
>> On Mon, Apr 19, 2010 at 8:45 AM, Michael G Schwern
>> wrote:
>>>
>>> Steffen Mueller wrote:
>
>
Or 2.1 once we really understand the implications of things that
people voted for but which turn out to be a disaster when we try to
implement them...
Adam K
On Mon, Apr 19, 2010 at 11:01 PM, David Golden wrote:
> Michael -- I appreciate the suggestion, but the spec is done. I did
> ask for com
That's not the problem.
The problem is how do you deal with multi-language dependencies in the
requires: (et al) parts of the META.yml.
Adam K
On Fri, Apr 16, 2010 at 10:17 AM, Ævar Arnfjörð Bjarmason
wrote:
> On Fri, Apr 16, 2010 at 00:07, Adam Kennedy wrote:
>> The complex
On Fri, Apr 16, 2010 at 10:23 AM, Jan Dubois wrote:
> On Thu, 15 Apr 2010, Adam Kennedy wrote:
> Meaning: there is a limit to the usefulness of playing around with file
> extensions (and protocol schemes). Given that changing the file extensions
> might create problems elsewhere it
The language key let you declare the language of the package itself.
However, that same language concept did not extend to the dependency
specification, which is only in terms of Perl 5 namespaces.
The complexity of a multi-language META specification (and I've
actually written one as an experime
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 wrote:
> On Thu, 15 Apr 2010, Barbie wrote:
>> On Thu,
On Fri, Apr 16, 2010 at 5:56 AM, Eric Wilhelm wrote:
>>I've been meaning to propose for a while that for CPAN Perl 5 we drop
>>support for everything other than tar.gz (we can talk about the need
>>for zip files later) and encourage a switch to something like
>>
>>D/DA/DAGOLDEN/Foo-Bar-1.23.cpan
>
On Thu, Apr 15, 2010 at 11:59 AM, Jesse Vincent wrote:
>> > I've been meaning to propose for a while that for CPAN Perl 5 we drop
>> > support for everything other than tar.gz (we can talk about the need
>> > for zip files later) and encourage a switch to something like
>> >
>> > D/DA/DAGOLDEN/Foo
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
wrote:
> Why don't we make the .cpan/.c6pan file (.c6pan) a JSON file, generated
> by PAUSE once the tarball is uploaded, with w
That should be "Perl 6 Applications"
On Thu, Apr 15, 2010 at 10:53 AM, Adam Kennedy wrote:
> Alternative option, when we switch to Perl 6 also take the opportunity
> to switch to a specific named extension.
>
> D/DA/DAGOLDEN/Foo-Bar-1.23.c6z
>
> The directory option
Alternative option, when we switch to Perl 6 also take the opportunity
to switch to a specific named extension.
D/DA/DAGOLDEN/Foo-Bar-1.23.c6z
The directory option doesn't cover the case where you are installing
from arbitrary URLs as supported by cpanplus, pip and cpanminus. The
perl6 directory
On Fri, Apr 2, 2010 at 4:11 AM, Michael G Schwern 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 diffs betw
I've said nothing till now, because I figured more noise wouldn't help much.
But I quite like the rsync daemon/proxy idea, and as it so happens I'm
attending the OzLabs Unconference in 3 weeks time to hang out with
Tridge, Rusty and the other Australia C/Kernel/Samba/RSync elites.
So I'd be happy
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 Hanse
(b) sounds like an interesting idea.
Adam K
On Fri, Feb 19, 2010 at 2:03 AM, David Golden wrote:
> On Thu, Feb 18, 2010 at 9:12 AM, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 wrote:
>> I of course ran `perl Makefile.PL ; make ; make testdistro ; make test` on
>> the
>> source directory before committing and encountered
File::HomeDir is _supposed_ to support overloading of home directories
via $ENV{HOME} at all times (even on Windows, where the HOME variable
doesn't exist).
We may need to add some special casing someone can demonstrate this
not working, perhaps we can ask the XDG for the home directory, and if
th
However, the format LIMITS the data.
YAML can describe more things than JSON, JSON can describe more things
than CSV and SQLite and friends.
If you go with arbitrary formats though, this does seem to lead you
towards a solution that involves tabular data rather than tree data,
so that you have th
... 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
The one main issue I can think of regarding JSON is that we need to
make sure we have a streaming parser, so that we don't need the entire
thing in memory. We already have some memory issues with CPAN on just
the highest-version index, and if we start pushing around all-version
indexes this will ju
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. Pull
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 asso
On Mon, Jan 4, 2010 at 11:56 AM, Eric Wilhelm wrote:
> An index with support for $n languages doesn't seem to
> gain much over $n similarly structured indexes.
If Parrot itself supports trans-language calls (which I'm led to
understand it can?) then a single index gives us the potentially huge
wi
Working from the inside outwards, the part we need first is probably
the permissions database, and then a PAUSE-like thing on top of that.
Adam K
On Sun, Jan 3, 2010 at 2:43 PM, Eric Wilhelm wrote:
> There has been some discussion, but not by anyone in a position to do
> something about it AFAIC
The FTP network can be reused without any real trouble.
But the current index, client and META.yml stuff are all completely
unusable for Perl 6.
That pretty much sums things up.
Adam K
On Sun, Jan 3, 2010 at 10:35 AM, David Golden wrote:
> The last discussion I recall getting into, I strongly
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 wrote:
> On Mon, Nov 2, 2009 at 7:45 PM, Ricardo Signes
> wrote:
>> * Adam Kennedy [2009-11-02T18:24:26]
>>> I'd like to p
On Sun, Nov 1, 2009 at 7:55 AM, Slaven Rezic wrote:
> David Golden wrote:
>>
>> On Fri, Oct 9, 2009 at 9:31 AM, Graham Barr wrote:
>>>
>>> On Oct 9, 2009, at 6:43 AM, David Golden wrote:
>>>
05. Schema
Proposal:
The META spec should come along with a formal schema definit
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 wrote:
> On Mon, Oct 12, 2009 at 10:08 AM, David Golden wrote:
>
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 wrote:
> On Fri, Oct 9, 2009 at 7:56 AM, David Golden wrote:
>> 33. Install Meta files and make them queryable
>>
>> Proposal: Using something like .packlist or Fi
Now is the time, I guess, to add a meta-proposal of sorts.
I had pondered doing this earlier, but felt it was out of place
compared to the other elements.
I'd like to propose that all changes to the META.yml be fully and
completely defined, without resort to the behaviour of external code.
That
Ack, it would appear my comments on the proposals are late by 5 minutes or so.
Please ignore, I shall move my additions (particularly the counter
consensus additions) to the Spec review once it arrives, since most of
my problems with this set of features are along the lines of "This
feature has no
I still think I prefer Zefram's approach, remove optional_features entirely.
Adam K
On Mon, Nov 2, 2009 at 10:27 PM, David Golden wrote:
> On Mon, Nov 2, 2009 at 4:25 AM, Zbigniew Lukasiak wrote:
>> I don't know the history of this, but - risking that I'll add
>> something already covered - I w
I concur with Tim Bunce, META.yml is a bad place for describing language.
-1
Adam K
Opposed, this is not the right forum to be attempting sweeping
language/library solutions of this kind (yet).
I have an potential alternative solution to this problem, outside of
the score of META.yml, that I'd like to see attempted first.
-1
Adam K
Opposed until someone can demonstrate working dependency algorithms
that take this into account.
-1
Adam K
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 like
This seems weird logic to me.
Adding it without 8 involves adding 1 extra category.
Adding it WITH 8 involves adding 3 extra categories (requires,
recommends and prefers).
Your logic is backwards I think.
+1 without 8
Adam K
Steffen Mueller
Fri, 09 Oct 2009 07:25:16 -0700
David Golden wrote:
49 matches
Mail list logo
