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.ors...@gmail.com> wrote: > > > > On Thu, Jun 6, 2013 at 7:42 PM, Jay McCarthy <jay.mccar...@gmail.com>wrote: > >> On Thu, Jun 6, 2013 at 8:17 AM, Sam Tobin-Hochstadt <sa...@ccs.neu.edu> >> wrote: >> > On Thu, Jun 6, 2013 at 10:00 AM, Matthew Flatt <mfl...@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 > >
_________________________ Racket Developers list: http://lists.racket-lang.org/dev