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

(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 <eli at barzilay.org> wrote:
> 
>     Yesterday, Laurent wrote:
>     > On Sun, Jun 2, 2013 at 1:47 PM, Eli Barzilay <eli at barzilay.org> 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 have thought that it would have
>     > just been a matter of creating a directory with the same name as the
>     > package, and then decompressing the package into that directory.
>    
>     At the lower level, packages use links, and "raco link"'s default mode
>     of work is at the collection level.  There is obviously a need for
>     packages that correspond to collection roots, but I wanted to see the
>     default being the same as the raco-link default (which fits most uses
>     that don't come out of the current main tree).
> 
> Not sure I was clear, or I don't exactly understand what you mean.
> And maybe I'm missing some important point here.
> 
> But the more I think about it, the less I see why this
> double-directory thing should be the default behavior of the new package
> system (I can understand why it's useful for plt packages though).
> Even Carl's "mischief" package doesn't make use of collections like
> that.
> Jen's "this-and-that" does, though, but then every collection of his
> package must have a name that is different from any existing collection.
> (And actually I think that's a bad idea, and that he should split his
> package into several single-collection packages −unless they are
> tightly related− because I don't want to install all his collections if I want
> to only try one of them, unless there is a way to install only one
> collection of an existing package?)
> 
> For example, my personal racket project tree is arranged somewhat like
> that:
> racket
> ├── project-B
> │   └── main.rkt
> ├── project-A
> │   └── main.rkt
> ├── not-yet(?)a-project-C
> ├── my-collects
> │   ├── slideshow
> │   ├── scribble
> │   ├── racket
> │   └── data
> └── misc
>     ├── try-this.rkt
>     └── try-that.rkt
> 
> project-A and project-B are git clones.
> my-collects contains all my extensions to racket's collections,
> plus some more generally useful collections.
> 
> For my personal use, I just do:
>   raco link project-A project-B my-collects
> and all is fine.
> I tend to believe it's a quite common tree for racket users.
> 
> In "my-collects", I have names that would collide with racket's collections,
> so instead of having:
> (require orseau/racket/slideshow)
> as in the former package system, I would now have
> (require some-funny-name/slideshow)
> after renaming my-collects to some-funny-name to make sure it does not
> collide with anything else.
> 
> ... and since I don't want to invent a funny name for each extension of a
> racket collection I do, I prefer to put them all in a single package and
> collection.
> 
> Now if I were to follow the new package system, I'd need to change my
> tree to:
> racket
> ├── misc
> │   ├── try-that.rkt
> │   └── try-this.rkt
> ├── some-funny-name
> │   └── some-funny-name
> │       ├── data
> │       ├── racket
> │       ├── scribble
> │       └── slideshow
> ├── not-yet(?)a-project-D
> ├── project-A
> │   └── project-A
> │       └── main.rkt
> └── project-B
>     └── project-B
>         └── main.rkt
> 
> which is a mess. And I would also need to change my git repos to
> match that structure, which looks awkward.
> /But/ I don't care if the tree of the packages I *install* look like that.
> 
> So what I would like is to keep my tree like the first one, but the
> package system can still install like the second one.
> 
> My proposal was that for single-collection packages, I could keep
> my tree like the first one, my git clones like project-A/main.rkt, and
> tell the package manager (probably in the info.rkt file) that it is a
> single-collection package so that when it installs it in the
> installed-package-directory-that-I-will-not-look-into it generates a tree
> like the second one.
> 
>     Well, the reason I think that plain collection packages are important
>     is it will simplify dealing with packages, and lower the investment
>     threshold that you need to publish a package.  Along the same line,
>     there should also be a way to put out just a single file (or very few)
>     as a first step where I make some code public but with absolutely
>     minimum effort on the publisher's side.  See for example the
>     "Processing" thread, where Sean said that people who do these kind of
>     thing "don't even know what source control is, let alone packages" --
>     so the existence of such a crowd is a perfect reason for a single-file
>     thing being another important point on the code distribution spectrum.
> 
> I entirely agree with that, and I think it is of utmost importance for a
> programming language (and system) to make sure that its users can
> easily share code. Probably all of you agree with that, but I want to
> emphasize that it's really important to put as much effort as required
> into that.
> 
> Don't get me wrong, I really like the steps forward taken with the new
> direction of the package system, but right now there's a psychological
> wall that prevents me from publishing more v2 packages.
> 
> Laurent
> 

-- 
          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!