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

On Thu, Jun 6, 2013 at 12: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.

You are correct that I see the separation of package-name and
code-to-require as a big feature. You also correct that right now this
can be a bit painful where it's not clear how they are connected.
However, I see that as a consequence of where we are in development.

My goal is to have a large xrefed documentation site of all ring-0
packages (we are close to this) so you can look up awesome or
slideshow-latex and then require it and have racket/DrRacket give you
a pop up that says, "Do you want to install package <blah> to get
this?" (I believe DrRacket does this now and we have xrepl that does
it too). Since ring-0 guarantees no conflicts, there is always a
unique answer to the require->package question.

In other words, my goal is to have only package authors ever concerned
with (a) their package names and (b) which package they are even
getting their modules from. UNLESS, you want to use ring-1 (untested)
or ring-2 (conflicting) packages---since using those rings is
inconvenient, it is incentivizes authors to remove conflicts and test
their code to get to ring-0. (In other words, I don't want any ring-1
or 2 packages.)

Jay


--
Jay McCarthy <jay at cs.byu.edu>
Assistant Professor / Brigham Young University
http://faculty.cs.byu.edu/~jay

"The glory of God is Intelligence" - D&C 93