[racket-dev] PLaneT(2): Single vs multi-collection packages

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, version B.0.1;


On Thu, Jun 6, 2013 at 2:31 PM, Laurent <laurent.orseau at gmail.com> wrote:

>
>
>
> On Thu, Jun 6, 2013 at 7:42 PM, Jay McCarthy <jay.mccarthy at gmail.com>wrote:
>
>> On Thu, Jun 6, 2013 at 8:17 AM, Sam Tobin-Hochstadt <samth at ccs.neu.edu>
>> wrote:
>> > On Thu, Jun 6, 2013 at 10:00 AM, Matthew Flatt <mflatt at cs.utah.edu>
>> 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 are the default, it is backward incompatible.
>> >>> If info.rkt exists, it looks for 'multi-collection, and otherwise
>> >>> looks for the 'collection-name string.
>> >>
>> >> I could go along with this, as long as (most?) everyone agrees, and as
>> >> long as package authors are willing to update existing packages.
>>
>> >
>> > 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 it brings in internal linking where
>> code directly refers to other packages (implementations) and not
>> modules (interfaces) as the default. This means we will see code like
>> (require jays-awesome-data-structure) rather than (require
>> data/awesome). I think this is bad because it makes it harder to deal
>> with forking, maintainers abandoning their code, splitting packages
>> into packages that just depend on 'jays-awesome-data-structure, rather
>> than implementing it internally, etc. Obviously you can still deal
>> with those things, but if the path of evolution we imagine starts off
>> with single-package-with-package/collection-name-shared, then most
>> packaged collections will have a package as their name.
>>
>
> Ok, I see your point.
> Let me try to make a use case here:
> User A writes package P on Github at A/P.
> A creates a PLaneT package also named P.
> User B forks P to B/P.
> Since the package name P is already taken, you expect B to name his
> package B-P.
> (But I think you make this point sufficiently clear in the docs that this
> should be very seldom.)
>
> So on installation, you have a collection name B-P, which is bad,
> because you cannot replace A's P directly by B's P, simply by
> uninstalling A's and installing B's.
>
> Now, the thing is you'd like B's collection to be name P also, right?
> (which means only one could be installed at the same time, otherwise we
> get back to the same problem, whatever the option we choose.)
>
> Now if we really want to have P as the default collection name for B's P,
> we could also probably use B's Github repo name. Is it retrievable from
> the downloaded package?
> We would then use this if available, or the package/directory name
> otherwise (I guess non-repo installations will be rare anyway).
>
> But then people would still write
> $ raco pkg install <jay-awesome-package>
> but would then need to write
> (require awesome)
>
> which is, in most cases, quite counter-intuitive: you'd need to state it
> clearly in the docs of the package, but you would still have "dyslexic"
> users
> asking why it doesn't work (like I have with you, btw, with
> slideshow-latex).
> And this will probably occur much more often than the case above,
> because you have many more users of packages than developers, and the
> default should be intuitive for the largest part.
>
> Laurent
>
>
>
> _________________________
>   Racket Developers list:
>   http://lists.racket-lang.org/dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20130606/f68ae189/attachment.html>