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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20130606/9e1665b4/attachment-0001.html>