Re: [racket-dev] experiment reorganizing the repo into packages
On Thursday, Matthew Flatt wrote: You've sketched out the producer side, and I'm not sure of some about some of those details. The consumer side seems even more complex to me. It seems like the package system would have to keep track of which subpackages are installed for a package, provide an interface to the user (e.g., in the GUI) for subpackages, and be able to update a package with new subpackages --- all while tracking dependencies at the level of subpackages. I'm sure it can all be done, but I'm not sure how difficult or important it will be relative to everything else that still needs to be done, and I'm pretty sure it can't all be done right now. A very cheap way to do this is to use these sub-package specifications only for creating packages for distribution. With the obvious resulting package file names, this means that there is no change at all that is needed on the consumer side. And I think that while it looks like it reduces the whole thing considerably, it's still worth it for some important advantages that are still kept: * No need to move files around in a distribution-oriented layout in code repositories (which is important since people really maintain the freedom of puting files in a way that fits their needs logically). * No restriction on a few known -foo names -- keeping it open for new kinds of package kinds. (Related note: I spoke to Ryan about having db in the minimal core and the possible reason for this being due to sqlite -- it would be nice, and according to Ryan not too difficult, to split the db package into several db-foo backends, which hooks back into my point of some splittings that make sense in just one package.) * Minimize code hacks that compensate for the lack of such sub-packages. There will still be some hacks -- for example, it will be convenient in the beginning to just show available package names and the end user will need to figure out what they mean, and when later on you want to grouping back packages that really came from a single source for the UI, instead of some hack that is based on names, it can use this information instead. All of these are important IMO, but the last one is particularly good, since hacking something based on naming conventions means that these hacks will stay around for a very long time -- which will lead to yet more hacks. In the spirit of making things usable, I also worry about accumulation of command-line flags, a problem that plagued .plt file generation and installation (making it into black magic that not many people could handle). Instead of trying to create subpackages, we might stick with a naming convention. Even with a naming convention, it might make sense to extend the package-manager GUI so that it recognizes the convention and groups related packages together in a list view (but all the machinery remains at the package level). (This is an example for the kind of hacks where some of them can be avoided with the above, and with others I think that it will be easier to recover proper code after a transition period with such hacks.) Also, a package implementor is free to develop subpackages along the lines you suggest, but splitting out the subpackages into packages before handling them to a catalog. (And having scripts to do such splitting by developers would not be needed at all.) Or, we could just not try to slice packages as finely for now, so that the -lib and -docs packages of the experimental split are merged together --- leaving a future split possibly to subpackages. That will most likely result in a coarse layering that is close to build-deps up to the drracket layer, but still provide more separation for things that are outside the layer needed by DrRacket itself; for example, games, redex, htdp, plai, picturing-programs, and plot can still be separate packages, I think. FWIW, I'd view this (avoid fine slicing) as a possible way to avoid growing hacks, but I really like the idea of smaller packages and the benefits it comes with. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
Yesterday, Laurent wrote: On Sun, Jun 2, 2013 at 1:47 PM, Eli Barzilay e...@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). TBH, the chances of implementing an `in-url' are low too, but they're probably higher than going into the package system. That would be nice, but I'd much much prefer to see the single-collection package thing implemented. 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. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] member like assoc
+1, and maybe also add a racket2 item to get rid of all of the unnecessary functions? (I think that member/assoc/etc are better with `eq?' than using memq/assq/etc.) Two days ago, Matthias Felleisen wrote: +1, do it. On May 31, 2013, at 7:40 PM, Asumu Takikawa wrote: Hi all, Is it feasible to get `member` to have the same optional argument behavior as `assoc`? That is, to have an equality predicate as the third argument. I find myself writing the (imaginary) equivalent of things like: (member id some-list free-identifier=?) and it seems like it would be nicer with an extra `member` argument than with `memf`. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] experiment reorganizing the repo into packages
At Mon, 3 Jun 2013 08:27:19 -0400, Eli Barzilay wrote: On Thursday, Matthew Flatt wrote: You've sketched out the producer side, and I'm not sure of some about some of those details. The consumer side seems even more complex to me. It seems like the package system would have to keep track of which subpackages are installed for a package, provide an interface to the user (e.g., in the GUI) for subpackages, and be able to update a package with new subpackages --- all while tracking dependencies at the level of subpackages. I'm sure it can all be done, but I'm not sure how difficult or important it will be relative to everything else that still needs to be done, and I'm pretty sure it can't all be done right now. A very cheap way to do this is to use these sub-package specifications only for creating packages for distribution. With the obvious resulting package file names, this means that there is no change at all that is needed on the consumer side. I don't understand the suggestion. As a concrete example, can you sketch our how a user installs the web-server package without documentation, and how the package manager later knows to upgrade the web-server package to include documentation when requested by the user? _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
On Mon, Jun 3, 2013 at 2:44 PM, Eli Barzilay e...@barzilay.org wrote: Yesterday, Laurent wrote: On Sun, Jun 2, 2013 at 1:47 PM, Eli Barzilay e...@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
Re: [racket-dev] experiment reorganizing the repo into packages
50 minutes ago, Matthew Flatt wrote: At Mon, 3 Jun 2013 08:27:19 -0400, Eli Barzilay wrote: A very cheap way to do this is to use these sub-package specifications only for creating packages for distribution. With the obvious resulting package file names, this means that there is no change at all that is needed on the consumer side. I don't understand the suggestion. As a concrete example, can you sketch our how a user installs the web-server package without documentation, and how the package manager later knows to upgrade the web-server package to include documentation when requested by the user? On the building side, you'd run some command/script/whatever that goes over the distribution kinds and generates a package for each -- so if you have (define distributions '([lib *.rkt] [doc *.scrbl scribblings])) the result will be web-server-lib.zip, web-server-doc.zip, and web-server.zip where the last one contains dependencies on the other two. (So this last one is the only one that is special since it's completely made up.) Then all of these files will get distributed in the same way they would be with the directory/repo split. (BTW, a possible source of confusion: I'm assuming that distribution must be done via archives and not via repository specs, since there should be some way to put the compiled files in there. You've mentioned at some point a binary catalog which seems unnecessary to me, but maybe there's something I don't get here.) Updates would happen in a similar way, with new zip files. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [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 e...@barzilay.org wrote: Yesterday, Laurent wrote: On Sun, Jun 2, 2013 at 1:47 PM, Eli Barzilay e...@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
[racket-dev] tr cycles in module graph
Apologies if this is a known issue When I write this: #lang typed/racket (module+ test (require typed/rackunit)) I get this (in DrRacket, default module language settings): Welcome to DrRacket, version 5.3.4.11--2013-06-03(54b45607/d) [3m]. Language: typed/racket; memory limit: 128 MB. . . ../../../../exp/plt/collects/typed-racket/env/env-req.rkt:9:4: standard-module-name-resolver: cycle in loading at path: /Users/robby/git/robby/compilers/lec/lecture13/x.rkt paths: /Users/robby/git/robby/compilers/lec/lecture13/x.rkt That seems to be a bug. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] tr cycles in module graph
OH, and if this is a known issue, I'd be most appreciative if someone could explain how I might be able to tell when I'm going to trigger this bug so I can avoid it when I do some TR programming in class tomorrow. (I know that a program that contains the program below plus some other stuff doesn't cause problems, but I can't quite see how to avoid the problem.) On Mon, Jun 3, 2013 at 9:46 AM, Robby Findler ro...@eecs.northwestern.eduwrote: Apologies if this is a known issue When I write this: #lang typed/racket (module+ test (require typed/rackunit)) I get this (in DrRacket, default module language settings): Welcome to DrRacket, version 5.3.4.11--2013-06-03(54b45607/d) [3m]. Language: typed/racket; memory limit: 128 MB. . . ../../../../exp/plt/collects/typed-racket/env/env-req.rkt:9:4: standard-module-name-resolver: cycle in loading at path: /Users/robby/git/robby/compilers/lec/lecture13/x.rkt paths: /Users/robby/git/robby/compilers/lec/lecture13/x.rkt That seems to be a bug. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] tr cycles in module graph
I think this is a known bug in the expander that's gotten worse. But I don't know, and the tests that involve submodules seem to pass. In general, submodules + Typed Racket make the expander unhappy, and this seems (although I'm not certain) that this is worse in DrRacket than otherwise. Sorry for not being more helpful. Sam On Mon, Jun 3, 2013 at 10:46 AM, Robby Findler ro...@eecs.northwestern.edu wrote: Apologies if this is a known issue When I write this: #lang typed/racket (module+ test (require typed/rackunit)) I get this (in DrRacket, default module language settings): Welcome to DrRacket, version 5.3.4.11--2013-06-03(54b45607/d) [3m]. Language: typed/racket; memory limit: 128 MB. . . ../../../../exp/plt/collects/typed-racket/env/env-req.rkt:9:4: standard-module-name-resolver: cycle in loading at path: /Users/robby/git/robby/compilers/lec/lecture13/x.rkt paths: /Users/robby/git/robby/compilers/lec/lecture13/x.rkt That seems to be a bug. _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #26926: master branch updated
Ah, so this is what made the scribble/reader tests fail -- thanks for the fix. But there's still a possible problem: v5.3.4: - (raise-read-error foo 'src 1 2 3 4) ; src:1:2: foo [,bt for context] Before this commit: - (raise-read-error foo 'src 1 2 3 4) ; #procedure:...ntax/readerr.rkt:33:21foo [,bt for context] And now: - (raise-read-error foo 'src 1 2 3 4) ; src:1:1: foo [,bt for context] where the column number is different from the first run. 20 minutes ago, ro...@racket-lang.org wrote: robby has updated `master' from 54b45607a2 to 1f22800d51. http://git.racket-lang.org/plt/54b45607a2..1f22800d51 =[ One Commit ]= Directory summary: 9.8% collects/syntax/ 90.1% collects/tests/syntax/ ~~ 1f22800 Robby Findler ro...@racket-lang.org 2013-06-03 08:38 : | fix bug introduced in 6b2a4ff5 : M collects/syntax/readerr.rkt | 1 + A collects/tests/syntax/test-readerr.rkt =[ Overall Diff ]=== collects/syntax/readerr.rkt ~~~ --- OLD/collects/syntax/readerr.rkt +++ NEW/collects/syntax/readerr.rkt @@ -30,6 +30,7 @@ (format ~a~a (cond [(not (error-print-source-location)) ] [(srcloc-string (srcloc source-name line col pos span)) + = (lambda (s) (format ~a: s))] [else ]) collects/tests/syntax/test-readerr.rkt ~~ --- /dev/null +++ NEW/collects/tests/syntax/test-readerr.rkt @@ -0,0 +1,9 @@ +#lang racket/base +(require rackunit syntax/readerr) + +(check-exn + (λ (x) + (and (exn:fail:read:eof? x) +(regexp-match #rx^y[01: ]* x (exn-message x + (λ () (raise-read-eof-error +x y 1 1 1 1))) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #26926: master branch updated
Yes, I noticed that too. It would be good if someone looked into it. Robby On Mon, Jun 3, 2013 at 9:57 AM, Eli Barzilay e...@barzilay.org wrote: Ah, so this is what made the scribble/reader tests fail -- thanks for the fix. But there's still a possible problem: v5.3.4: - (raise-read-error foo 'src 1 2 3 4) ; src:1:2: foo [,bt for context] Before this commit: - (raise-read-error foo 'src 1 2 3 4) ; #procedure:...ntax/readerr.rkt:33:21foo [,bt for context] And now: - (raise-read-error foo 'src 1 2 3 4) ; src:1:1: foo [,bt for context] where the column number is different from the first run. 20 minutes ago, ro...@racket-lang.org wrote: robby has updated `master' from 54b45607a2 to 1f22800d51. http://git.racket-lang.org/plt/54b45607a2..1f22800d51 =[ One Commit ]= Directory summary: 9.8% collects/syntax/ 90.1% collects/tests/syntax/ ~~ 1f22800 Robby Findler ro...@racket-lang.org 2013-06-03 08:38 : | fix bug introduced in 6b2a4ff5 : M collects/syntax/readerr.rkt | 1 + A collects/tests/syntax/test-readerr.rkt =[ Overall Diff ]=== collects/syntax/readerr.rkt ~~~ --- OLD/collects/syntax/readerr.rkt +++ NEW/collects/syntax/readerr.rkt @@ -30,6 +30,7 @@ (format ~a~a (cond [(not (error-print-source-location)) ] [(srcloc-string (srcloc source-name line col pos span)) + = (lambda (s) (format ~a: s))] [else ]) collects/tests/syntax/test-readerr.rkt ~~ --- /dev/null +++ NEW/collects/tests/syntax/test-readerr.rkt @@ -0,0 +1,9 @@ +#lang racket/base +(require rackunit syntax/readerr) + +(check-exn + (λ (x) + (and (exn:fail:read:eof? x) +(regexp-match #rx^y[01: ]* x (exn-message x + (λ () (raise-read-eof-error +x y 1 1 1 1))) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
Here is a patch for a proof of concept (file /collects/pkg/lib.rkt). The modifications are minimal as I had expected, but obviously I only have a very narrow view of the package system, so probably something does not work properly. In particular, I changed only for the 'dir type, and did not touch the 'link type. Since the 'github type and others use the 'dir type once the archive is downloaded, I think it should work as expected for those too. I've tested on an old 5.3.4.10--2013-05-13(96acfb0/a) [3m], but made the patch with the latest in git, and it still works with the old version. (I was about to test it with the latest nightly, but its installation failed, see the mailing list) To try it, in the collects/pkg directory: $ patch lib.rkt lib.rkt.patch $ sudo raco setup -D pkg Then create a dummy package: $ cd /tmp $ mkdir dummy $ echo '#lang racket\n(displayln It works!)' dummy/main.rkt $ touch dummy/single-collect The file single-collect is here to signal that this package is a single-collection package (it's not the right way to do it, but it's a proof of concept). Install the package: $ raco pkg install -t dir dummy (You should see This is a single-collection package as the first line of the log) Then try it: $ racket (require dummy) It works! Or is this patch way too naive for some reason? Laurent On Mon, Jun 3, 2013 at 4:37 PM, Eli Barzilay e...@barzilay.org wrote: (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 e...@barzilay.org wrote: Yesterday, Laurent wrote: On Sun, Jun 2, 2013 at 1:47 PM, Eli Barzilay e...@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
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
Oh, and test cases would go here: https://github.com/plt/racket/blob/master/collects/tests/pkg/tests-create.rkt and https://github.com/plt/racket/blob/master/collects/tests/pkg/tests-install.rkt On Mon, Jun 3, 2013 at 10:44 AM, Jay McCarthy jay.mccar...@gmail.com wrote: You would need to update the metadata calculation, such as https://github.com/plt/racket/blob/master/collects/pkg/lib.rkt#L154 and you should deal with the non-proof of concept method of specifying it in, for instance, the info file, which is now package info AND collect info. Finally, you have to deal with how to say what the name of the collection is, because it can't be derived only from the source, because we want to be able to have package-from-20130203.tgz have collections other than package-from-20130203 in it. Jay On Mon, Jun 3, 2013 at 10:37 AM, Laurent laurent.ors...@gmail.com wrote: Here is a patch for a proof of concept (file /collects/pkg/lib.rkt). The modifications are minimal as I had expected, but obviously I only have a very narrow view of the package system, so probably something does not work properly. In particular, I changed only for the 'dir type, and did not touch the 'link type. Since the 'github type and others use the 'dir type once the archive is downloaded, I think it should work as expected for those too. I've tested on an old 5.3.4.10--2013-05-13(96acfb0/a) [3m], but made the patch with the latest in git, and it still works with the old version. (I was about to test it with the latest nightly, but its installation failed, see the mailing list) To try it, in the collects/pkg directory: $ patch lib.rkt lib.rkt.patch $ sudo raco setup -D pkg Then create a dummy package: $ cd /tmp $ mkdir dummy $ echo '#lang racket\n(displayln It works!)' dummy/main.rkt $ touch dummy/single-collect The file single-collect is here to signal that this package is a single-collection package (it's not the right way to do it, but it's a proof of concept). Install the package: $ raco pkg install -t dir dummy (You should see This is a single-collection package as the first line of the log) Then try it: $ racket (require dummy) It works! Or is this patch way too naive for some reason? Laurent On Mon, Jun 3, 2013 at 4:37 PM, Eli Barzilay e...@barzilay.org wrote: (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 e...@barzilay.org wrote: Yesterday, Laurent wrote: On Sun, Jun 2, 2013 at 1:47 PM, Eli Barzilay e...@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.
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
You would need to update the metadata calculation, such as https://github.com/plt/racket/blob/master/collects/pkg/lib.rkt#L154 and you should deal with the non-proof of concept method of specifying it in, for instance, the info file, which is now package info AND collect info. Finally, you have to deal with how to say what the name of the collection is, because it can't be derived only from the source, because we want to be able to have package-from-20130203.tgz have collections other than package-from-20130203 in it. Jay On Mon, Jun 3, 2013 at 10:37 AM, Laurent laurent.ors...@gmail.com wrote: Here is a patch for a proof of concept (file /collects/pkg/lib.rkt). The modifications are minimal as I had expected, but obviously I only have a very narrow view of the package system, so probably something does not work properly. In particular, I changed only for the 'dir type, and did not touch the 'link type. Since the 'github type and others use the 'dir type once the archive is downloaded, I think it should work as expected for those too. I've tested on an old 5.3.4.10--2013-05-13(96acfb0/a) [3m], but made the patch with the latest in git, and it still works with the old version. (I was about to test it with the latest nightly, but its installation failed, see the mailing list) To try it, in the collects/pkg directory: $ patch lib.rkt lib.rkt.patch $ sudo raco setup -D pkg Then create a dummy package: $ cd /tmp $ mkdir dummy $ echo '#lang racket\n(displayln It works!)' dummy/main.rkt $ touch dummy/single-collect The file single-collect is here to signal that this package is a single-collection package (it's not the right way to do it, but it's a proof of concept). Install the package: $ raco pkg install -t dir dummy (You should see This is a single-collection package as the first line of the log) Then try it: $ racket (require dummy) It works! Or is this patch way too naive for some reason? Laurent On Mon, Jun 3, 2013 at 4:37 PM, Eli Barzilay e...@barzilay.org wrote: (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 e...@barzilay.org wrote: Yesterday, Laurent wrote: On Sun, Jun 2, 2013 at 1:47 PM, Eli Barzilay e...@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
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
At Mon, 3 Jun 2013 18:37:43 +0200, Laurent wrote: Here is a patch for a proof of concept (file /collects/pkg/lib.rkt). The modifications are minimal as I had expected, but obviously I only have a very narrow view of the package system, so probably something does not work properly. In particular, I changed only for the 'dir type, and did not touch the 'link type. Since the 'github type and others use the 'dir type once the archive is downloaded, I think it should work as expected for those too. Thanks --- I appreciate your willingness to contribute! Speaking for myself, I'd like to see a full implementation rather than a proof of concept. In this case, I've implemented the idea once before, and so I know it's basically possible. But I didn't like how the details worked out in my approach, so I'm hoping that someone will find a better approach to the details. Unfortunately, that really requires getting into all the details. I'll echo Jay's observation that this patch's implementation leaves a single-collection package's installation without an info.rkt file, which is needed for information like package-level dependencies. The simplification of not handling links also seems like a big weakness to me. I think one of the best things about Jay's design is that I don't have to change the way I think about a package when moving between link and non-link modes (which makes it much easier to work with a GitHub repository, for example). I particularly encourage you to think about what should happen when a user needs to transition a GitHub repo from a representing a single-collection package to a multiple-collection package --- and how that interacts with links as well as non-link, GitHub-based installations of the package. Meanwhile, as we've started leaning on the package system and looked at how to fit our current collections into it, I think we're running into the same problem at another level: if web-server-lib and web-server-doc are both packages in a single web-server repository, and if they have to be separate directories, then we have yet another layer of directories that affect repository layout. Maybe there's a more general answer to the directory-layout problem that would neatly cover single-collection packages. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] experiment reorganizing the repo into packages
At Mon, 3 Jun 2013 10:36:51 -0400, Eli Barzilay wrote: (BTW, a possible source of confusion: I'm assuming that distribution must be done via archives and not via repository specs, since there should be some way to put the compiled files in there. I don't think that's the right assumption. We want it to have packages that combine source with built entities, but I don't think we want to require it. Requiring it would break the way GitHub repositories are meant to be used as packages. You've mentioned at some point a binary catalog which seems unnecessary to me, but maybe there's something I don't get here.) Yes, binary packages are another way to address the underlying issue. I'm going to try to synthesize the progress and discussion so far in a new message, and hopefully I'll managed to explain binary packages this time around. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] PLaneT(2): Single vs multi-collection packages
and you should deal with the non-proof of concept method of specifying it in, for instance, the info file, which is now package info AND collect info. Finally, you have to deal with how to say what the name of the collection is, because it can't be derived only from the source, Perhaps could handle both with one info.rkt item: ;; info.rkt #lang setup/infotab (define single-collection-package collection-name) ;; I am a single collection package and I am named this. ;; Else if absent assume status quo subdir collection(s) Speaking of which, it's not just the extra subdir. The existence of two info.rkt files was confusing (to me) at first, although it made sense in hindsight. Now that I'm accustomed it to the extra subdir isn't a huge annoyance, but I do find myself feeling like Sheldon Cooper on TBBT whenever I type triples like collect/collect/collect.rkt. _ Racket Developers list: http://lists.racket-lang.org/dev
