On Mon, Jun 3, 2013 at 7:36 PM, Matthew Flatt <mfl...@cs.utah.edu> wrote:
> 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. > Actually I use collection links instead of package links for my single-collection packages, which are Github clones. It kind of makes sense. (One more homogeneous possibility would be to add a `raco pkg install --link-single <my-collect/package>` command that is just a synonym for `raco link <my-collect/package>`. Actually I would much prefer to have `raco pkg install --link` work like `raco link` and have an additional `raco pkg install --link-multi` command instead.) As Greg suggested, the single-collection package would have only one info.rkt file (which is simpler for the user[*]), and would contain both the info for the package and for the collection. As they seem to have mutually-exclusive information, it should be ok. (But one would have to be sure that this will remain the case in the future but I think it should hold. I think it should be ok too, see at the bottom of the email.) E.g., dependencies of a single collection fit well in the collection's info.rkt I think (meaning these are the dependencies of the collection). When installing the package with 'dir, the collection gets its own subdir, and the info.rkt file just needs to be copied in the package directory. When changing from a single-collection to a multi-collection package, you'd have to do (I think): - collect-unlink the current package, - move the collection to a subdirectory (along with the info.rkt file), - create a info.rkt file in the package root, and move the parts of the collection's info.rkt that are package-specific to this new file, - package-link the new package. Since I don't expect people (other than the Racket dev) to do that often (or even at all for most of them), I don't see that's a problem (it's not even a big deal). When someone wants to do that, it means he already has some good knowledge about collections and packages (since he wants to build a multi-collection package), and thus it should not be a problem either. You could generalize the principle: - When all you need is a file, just use a file. It should have all the necessary information (i.e., why not have a 'info' submodule? E.g. to deal with dependencies) - If you need several files, create a folder, put your files in there, and add a collection-specific file (info.rkt) - if you need several collections (a package), create a new folder, put your collections in there, add a file that is specific to the collection of collections (the package) - if you need several packages (a repository?), create a new folder, put your packages in there, etc. - etc. The info.rkt files that are closer to the root are more general, and more specific info.rkt files should have precedence in case there is a conflict (like in CSS for example). I expect the first two cases to be overwhelmingly dominant, and thus they should be easier to achieve. Laurent [*] I think a good tool is one that asks for Minimum User Effort, and if the user wants to do something simple, it should be simple to achieve.
_________________________ Racket Developers list: http://lists.racket-lang.org/dev
