Matthew Flatt wrote at 06/18/2013 07:59 AM:
In principle, you should add a versioned dependency on "racket" to
indicate that the package does not work with version 5.3.4, and so
users of v5.3.4 should get an earlier revision of the package.
Just a general comment... For production use, I try no
At Mon, 17 Jun 2013 16:53:50 -0400, Greg Hendershott wrote:
> I'm still thinking that I'll keep my existing multi-collection
> packages as multi, to preserve compatibility with 5.3.4. Only because,
> although my packages don't have many users, I'll err on the side of
> their convenience.
>
> But i
I'm still thinking that I'll keep my existing multi-collection
packages as multi, to preserve compatibility with 5.3.4. Only because,
although my packages don't have many users, I'll err on the side of
their convenience.
But if someone else did want to change from multi to single:
1. Philosophica
I vote for this change too.
I've been letting my planet packages sit in planet for too long now.
This change provides a bit nicer upgrade path. :)
Vincent St-Amour writes:
> I vote for this change.
>
> I'm happy to change my packages (which make more sense as
> single-collection packages anyway)
On Sat, Jun 15, 2013 at 11:19 AM, Matthew Flatt wrote:
> For the new "info.rkt" field, should it be
>
> (define multi-collection? #t)
>
> ?
That seems fine.
_
Racket Developers list:
http://lists.racket-lang.org/dev
At Fri, 14 Jun 2013 21:14:58 -0400, Greg Hendershott wrote:
> I just want to be clear what I need to do to
> keep compatibility with 5.3.4 for existing packages. If that means
> adding something to info.rkt to say, "yeah, I'm still multi", I may do
> that.
Yes, that's exactly what will be required
I've been hesitant to comment on any of this, for three reasons: (1)
I've read the new package system documentation on at least 3 separate
occasions, and -- perhaps because I'm biased by having already formed
some ideas about where I'd like things to go -- I've had trouble
understanding the rat
Oh. I thought the proposal was that packages would remain multi
collection by default, and you'd add something like (define
single-collection "name") in info.rkt to opt for single. And the work
for current packagers would be if they wanted to change from multi to
single.
But I'm fine either way.
> I think more people need to speak up on this question --- particularly
> authors of existing packages, since the current proposal necessitates
> an update to each existing package.
>
> The proposal is to make single-package collections the default:
Fine by me: the only package I've contributed
I vote for this change.
I'm happy to change my packages (which make more sense as
single-collection packages anyway).
If I understand correctly, this would also have the advantage of making
a lot of github repositories (including most of mine) installable as
packages automatically, no change requ
Agreed. This looks good.
-Ian
- Original Message -
From: "Carl Eastlund"
To: "Matthew Flatt"
Cc: dev@racket-lang.org
Sent: Friday, June 14, 2013 10:42:06 AM GMT -05:00 US/Canada Eastern
Subject: Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
I
I vote for this change. I'll happily update my package in order to make it
easier for others to contribute new ones.
Carl Eastlund
On Fri, Jun 14, 2013 at 10:07 AM, Matthew Flatt wrote:
> I think more people need to speak up on this question --- particularly
> authors of existing packages, si
I think more people need to speak up on this question --- particularly
authors of existing packages, since the current proposal necessitates
an update to each existing package.
The proposal is to make single-package collections the default:
* If a directory used as a package has no "info.rkt" fi
Thank you for the thorough explanation.
Also, I'm having the "duh" moment I predicted.
A collection may have modules in subdirs and still be just one collection.
The use case for a multi-collection package is when you have
collections A and B that you want to be packaged and installed
together -
On Fri, Jun 7, 2013 at 2:49 PM, Greg Hendershott
wrote:
>> I am *very* strongly in favor of this -- I'd rather have
>> single-collection packages than multi-collection packages, if forced
>> to choose. I'm very glad that you and Laurent have done the work here.
>>
>> I'd be happy to update all of
> I am *very* strongly in favor of this -- I'd rather have
> single-collection packages than multi-collection packages, if forced
> to choose. I'm very glad that you and Laurent have done the work here.
>
> I'd be happy to update all of my packages. Currently, of my 9
> packages on pkg.racket-lang
On Thu, Jun 6, 2013 at 12:31 PM, Laurent wrote:
>
>
>
> On Thu, Jun 6, 2013 at 7:42 PM, Jay McCarthy wrote:
>>
>> On Thu, Jun 6, 2013 at 8:17 AM, Sam Tobin-Hochstadt
>> wrote:
>> > On Thu, Jun 6, 2013 at 10:00 AM, Matthew Flatt
>> > wrote:
>> >>
>> >>
>> >>> What I'd like is to have single-coll
Can't this be alleviated by the guidance on naming that the docs already
provide?
Sam
On Jun 6, 2013 2:30 PM, "Jay McCarthy" wrote:
> On Thu, Jun 6, 2013 at 12:03 PM, Sam Tobin-Hochstadt
> wrote:
> > On Thu, Jun 6, 2013 at 1:42 PM, Jay McCarthy
> wrote:
> >>
> >>> I am *very* strongly in favor
What if the differentiation between User A and User B's Package P were
encoded in the version number, instead of the name. Semantically, that's
what we're dealing with, two different versions of the same package.
Directly after a fork, the packages would be Package P, version A.1.15, and
Package P,
On Thu, Jun 6, 2013 at 7:42 PM, Jay McCarthy wrote:
> On Thu, Jun 6, 2013 at 8:17 AM, Sam Tobin-Hochstadt
> wrote:
> > On Thu, Jun 6, 2013 at 10:00 AM, Matthew Flatt
> wrote:
> >>
> >>
> >>> What I'd like is to have single-collection being the default [...]
> >>>
> >>> So here is a demo patch a
On Thu, Jun 6, 2013 at 12:03 PM, Sam Tobin-Hochstadt wrote:
> On Thu, Jun 6, 2013 at 1:42 PM, Jay McCarthy wrote:
>>
>>> I am *very* strongly in favor of this -- I'd rather have
>>> single-collection packages than multi-collection packages, if forced
>>> to choose. I'm very glad that you and Laur
On Thu, Jun 6, 2013 at 1:42 PM, Jay McCarthy wrote:
>
>> I am *very* strongly in favor of this -- I'd rather have
>> single-collection packages than multi-collection packages, if forced
>> to choose. I'm very glad that you and Laurent have done the work here.
>
> The main problem with this is that
On Thu, Jun 6, 2013 at 8:17 AM, Sam Tobin-Hochstadt wrote:
> On Thu, Jun 6, 2013 at 10:00 AM, Matthew Flatt wrote:
>>
>>
>>> What I'd like is to have single-collection being the default [...]
>>>
>>> So here is a demo patch attached to precise what I mean (without
>>> test, would have taken me wa
At Thu, 6 Jun 2013 10:17:28 -0400, Sam Tobin-Hochstadt wrote:
> > If we go that way, then I'd characterize a single-collection package
> > without 'single-collection' in "info.rkt" as a low-quality package, but
> > a low-quality package is a fine starting point for a high-quality
> > package.
>
>
> If info.rkt does not exist, it creates it and gives the 'collection-name
> > the name of the package by default.
>
> That doesn't seem like a good idea to me. As you've noted, there can be
> problems with writing extra files. The collection name could be instead
> computed in `pkg-single-collecti
On Thu, Jun 6, 2013 at 10:00 AM, Matthew Flatt wrote:
>
>
>> What I'd like is to have single-collection being the default [...]
>>
>> So here is a demo patch attached to precise what I mean (without
>> test, would have taken me way too much time). Because it considers
>> that single-collections ar
At Thu, 6 Jun 2013 13:36:38 +0200, Laurent wrote:
> > Some other the details:
> >
> > * A package's mode is recorded in the installed-package table.
> >Otherwise, a linked package could switch modes just because the
> >package directory's content changes, which would be difficult to
> >
Great! Thank you very much.
On Wed, Jun 5, 2013 at 11:04 PM, Matthew Flatt wrote:
> More generally, I hope I haven't come across as being firmly opposed to
> the idea of single-collection packages. I intended to come across as
> being opposed to implementing the idea myself. :)
>
I wanted to gi
At Tue, 4 Jun 2013 07:41:53 -0400, Eli Barzilay wrote:
> Yesterday, Jay McCarthy wrote:
> > and you should deal with the non-proof of concept method of
> > specifying it in, for instance, the info file, which is now package
> > info AND collect info.
>
> This shouldn't be a problem
At Tue, 4 Jun
Yesterday, Jay McCarthy wrote:
> and you should deal with the non-proof of concept method of
> specifying it in, for instance, the info file, which is now package
> info AND collect info.
This shouldn't be a problem -- *most* of the information in the info
files that we have now is really informat
On Mon, Jun 3, 2013 at 7:36 PM, Matthew Flatt wrote:
> The simplification of not handling links also seems like a big weakness
> to me. I think one of the best things about Jay's design is that I
> don't have to change the way I think about a package when moving
> between link and non-link modes
> and you should deal with the non-proof of concept method of specifying
> it in, for instance, the info file, which is now package info AND
> collect info.
>
> Finally, you have to deal with how to say what the name of the
> collection is, because it can't be derived only from the source,
Perhaps
At Mon, 3 Jun 2013 18:37:43 +0200, Laurent wrote:
> Here is a patch for a proof of concept (file /collects/pkg/lib.rkt).
>
> The modifications are minimal as I had expected, but obviously I only have
> a very narrow view of the package system, so probably something does not
> work properly.
> In pa
You would need to update the metadata calculation, such as
https://github.com/plt/racket/blob/master/collects/pkg/lib.rkt#L154
and you should deal with the non-proof of concept method of specifying
it in, for instance, the info file, which is now package info AND
collect info.
Finally, you have
Oh, and test cases would go here:
https://github.com/plt/racket/blob/master/collects/tests/pkg/tests-create.rkt
and
https://github.com/plt/racket/blob/master/collects/tests/pkg/tests-install.rkt
On Mon, Jun 3, 2013 at 10:44 AM, Jay McCarthy wrote:
> You would need to update the metadata calcul
Here is a patch for a proof of concept (file /collects/pkg/lib.rkt).
The modifications are minimal as I had expected, but obviously I only have
a very narrow view of the package system, so probably something does not
work properly.
In particular, I changed only for the 'dir type, and did not touch
(I completely agree with you, so I'll take it off-line.)
30 minutes ago, Laurent wrote:
> On Mon, Jun 3, 2013 at 2:44 PM, Eli Barzilay wrote:
>
> Yesterday, Laurent wrote:
> > On Sun, Jun 2, 2013 at 1:47 PM, Eli Barzilay wrote:
> >
> > To clarify, because of reasons that I
On Mon, Jun 3, 2013 at 2:44 PM, Eli Barzilay wrote:
> Yesterday, Laurent wrote:
> > On Sun, Jun 2, 2013 at 1:47 PM, Eli Barzilay wrote:
> >
> > To clarify, because of reasons that I won't go into on the list,
> > the actual chances of me getting this implemented (and of such a
> > ch
Yesterday, Laurent wrote:
> On Sun, Jun 2, 2013 at 1:47 PM, Eli Barzilay wrote:
>
> To clarify, because of reasons that I won't go into on the list,
> the actual chances of me getting this implemented (and of such a
> change being accepted) are pretty much in the area of "slim to
>
On Sun, Jun 2, 2013 at 1:47 PM, Eli Barzilay wrote:
> To clarify, because of reasons that I won't go into on the list, the
> actual chances of me getting this implemented (and of such a change
> being accepted) are pretty much in the area of "slim to none".
That's a bummer. At first sight I'd h
To clarify, because of reasons that I won't go into on the list, the
actual chances of me getting this implemented (and of such a change
being accepted) are pretty much in the area of "slim to none". TBH,
the chances of implementing an `in-url' are low too, but they're
probably higher than going i
Ah, that's cool. Looking forward to it!
And the in-url thing would be useful indeed for gists for example.
Laurent
On Thu, May 30, 2013 at 8:32 PM, Eli Barzilay wrote:
> Yes, I really want to try and get to look into doing this. The thing
> is that multi-collection libraries are going to be a
Yes, I really want to try and get to look into doing this. The thing
is that multi-collection libraries are going to be a common case for
plt packages (which will get pulled out from the main repository), but
the single-collection ones are going to be the much more popular case
elsewhere.
(And I
The Racket package system doesn't support packages that aren't
collection roots. Eli has said that he wants to implement such a
feature, but it is not available today.
Jay
On Thu, May 30, 2013 at 8:29 AM, Laurent wrote:
> I'm willing to upgrade my packages for the new PLaneT system, but one thin
I'm willing to upgrade my packages for the new PLaneT system, but one thing
that pushes me back is the fact that I need to create a directory for my
package and a subdirectory for the collection(s).
But most of my packages are (and will probably be) single-collection
packages, and it hurts my logi
45 matches
Mail list logo
