[racket-dev] current packages' docs, errors, and conflicts
I've been working on a service that builds all packages listed at pkgs.racket-lang.org. The idea is to run builds regularly (at least once a day) and link to documentation and build-status information from pkgs.racket-lang.org. Here's a table showing the current results for each package: http://www.cs.utah.edu/~mflatt/tmp/pkg-build/ Overall, there's still some work to do before this service can can go live, but I think it's getting close. Currently, a package fails to install if it depends on a PLaneT package --- even a compatibility variant from planet-compats.racket-lang.org. That limitation could be removed with more work, but I think it's probably better to get all packages that we care about onto pkgs.racket-lang.org. The rightmost column of the table may need some explanation. The column highlights conflicts among names of package-installed executables, foreign libraries, and documents. Currently, all the conflicts are document names, because several packages have a documents named simply manual or main. Overlapping documentation names cause no trouble among packages in user scope, which is why this problem has gone mostly unnoticed. Packages in installation scope, however, must have distinct document names, because installation-scope documentation goes to a single directory. So, to support installation scope, various packages need to be updated to give a more specific name to generated documentation. The implementation of the build service is `meta/pkg-build/main` in the Racket repo. The build service relies on VirtualBox MV instances to sandbox package builds, and the complexity is related to handling failure and making the build incremental (so that a small amount of work can be done if a small number of packages need to be rebuilt). It's still a work in progress, but I'm happy to provide more details if anyone wants to try it out. A full package build takes about an hour on my laptop, in addition to the 45 minutes or so to build a snapshot distribution from scratch. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] current packages' docs, errors, and conflicts
On Tue, 2014-07-08 at 12:46 +0100, Matthew Flatt wrote: The rightmost column of the table may need some explanation. The column highlights conflicts among names of package-installed executables, foreign libraries, and documents. Currently, all the conflicts are document names, because several packages have a documents named simply manual or main. Can you provide some guidelines on docs naming? I am responsible for half of the conflicts. :-) Best regards, Jan Dvorak _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] current packages' docs, errors, and conflicts
At Tue, 08 Jul 2014 14:08:27 +0200, Jan Dvořák wrote: On Tue, 2014-07-08 at 12:46 +0100, Matthew Flatt wrote: The rightmost column of the table may need some explanation. The column highlights conflicts among names of package-installed executables, foreign libraries, and documents. Currently, all the conflicts are document names, because several packages have a documents named simply manual or main. Can you provide some guidelines on docs naming? I am responsible for half of the conflicts. :-) A package X that provides a collection X of the same name should probably also call its documentation X. If the package provides both guide and reference documentation, then X-guide and X-reference are good choices. Thanks for looking into this! I've recently updated the Racket documentation, but I expect that more is needed. As far as I can tell, nothing in our documentation previously suggested that documentation names needs to be distinct. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] current packages' docs, errors, and conflicts
On Tue, Jul 8, 2014 at 8:14 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Tue, 08 Jul 2014 14:08:27 +0200, Jan Dvořák wrote: On Tue, 2014-07-08 at 12:46 +0100, Matthew Flatt wrote: The rightmost column of the table may need some explanation. The column highlights conflicts among names of package-installed executables, foreign libraries, and documents. Currently, all the conflicts are document names, because several packages have a documents named simply manual or main. Can you provide some guidelines on docs naming? I am responsible for half of the conflicts. :-) A package X that provides a collection X of the same name should probably also call its documentation X. If the package provides both guide and reference documentation, then X-guide and X-reference are good choices. Thanks for looking into this! I've recently updated the Racket documentation, but I expect that more is needed. As far as I can tell, nothing in our documentation previously suggested that documentation names needs to be distinct. Is there a reason we can't just make this work with duplicate names instead? Perhaps disambiguiating by collection name? I think this would change all the current URLs on docs.racket-lang.org, so we'd have to fix that, but it seems better to make us do a fixed amount of work rather than push this coordination problem onto everyone who writes packages in the future. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] current packages' docs, errors, and conflicts
On Tue, 2014-07-08 at 13:14 +0100, Matthew Flatt wrote: A package X that provides a collection X of the same name should probably also call its documentation X. Thanks, I've fixed mine. Looking forward to having pkg-docs at a single place. :-) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] current packages' docs, errors, and conflicts
On Tue, Jul 8, 2014 at 11:35 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Tue, 8 Jul 2014 10:15:10 -0400, Sam Tobin-Hochstadt wrote: - I wonder if using Docker instead of VirtualBox could make incrementality easier, since that's one of things that they focus on. I don't think it would be easier, but it might be more efficient and even easier to set up, so it seems worth trying. If you're interested in trying that, the information below should help you get oriented. I'll look into this. - I wanted to be able to see which of my packages had problems, so I wrote this PR: https://github.com/plt/racket/pull/721 but I'm not sure how to test it. I've merged and tweaked that change, but maybe you want to make more changes... I don't have a good way to try it other than to run a full build. Great, that's what I figured. - I think we need to support planet packages -- there are some people still releasing new ones, and there are old ones would take non-trivial work to port. Supporting Planet packages is a lot of work. Overcoming constrained network access in the sandbox is the most obvious problem and probably easy to solve. A more subtle and important piece of the puzzle is the notion of built packages, which can be quickly installed for dependent packages or for assembling documentation at the end. Planet packages don't have a built concept, and a package that depends on a Planet package won't have the right built properties: it will install, but not quickly. I think we're much better off moving Planet packages to supported packages in the new package system --- at least, for use by packages in the new package system. i was mostly thinking of handling packages from planet-compat.racket-lang.org, which would avoid (some of) the network access issues and perhaps also the built package issues. But maybe the problem then just reappears for the regular Planet packages that the planet-compat packages depend on? Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] current packages' docs, errors, and conflicts
At Tue, 8 Jul 2014 11:49:49 -0400, Sam Tobin-Hochstadt wrote: On Tue, Jul 8, 2014 at 11:35 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Tue, 8 Jul 2014 10:15:10 -0400, Sam Tobin-Hochstadt wrote: - I think we need to support planet packages -- there are some people still releasing new ones, and there are old ones would take non-trivial work to port. Supporting Planet packages is a lot of work. Overcoming constrained network access in the sandbox is the most obvious problem and probably easy to solve. A more subtle and important piece of the puzzle is the notion of built packages, which can be quickly installed for dependent packages or for assembling documentation at the end. Planet packages don't have a built concept, and a package that depends on a Planet package won't have the right built properties: it will install, but not quickly. I think we're much better off moving Planet packages to supported packages in the new package system --- at least, for use by packages in the new package system. i was mostly thinking of handling packages from planet-compat.racket-lang.org, which would avoid (some of) the network access issues and perhaps also the built package issues. But maybe the problem then just reappears for the regular Planet packages that the planet-compat packages depend on? I think the planet-compat packages have been converted to depend on other planet-compat packages. Maybe they'll work out, but it doesn't seem worth the effort to me. Support for those packages to date has been good and valuable, but we could reasonably draw the line at this point. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Release for v6.1 has begun
The release process for v6.1 has begun: the `release' branch was created for any work that is left and is now bumped to v6.0.900.900. You can go on using the `master' branch as usual, it is now bumped to v6.1.0.1 (to avoid having two different trees with the same version). If you have any bug-fixes and changes that need to go in the release then make sure to specify that in the commit message or mail me the commit SHA1s. You can `git checkout release' to try it out directly if needed -- but do not try to push commits on it (the server will forbid it). Please make sure that code that you're responsible for is as stable as possible, and let me know if there is any new work that should not be included in this release. NOW IS THE TIME TO FIX BUGS THAT YOU KNOW ABOUT The time between the `release' branch creation and the actual release is for fixing new errors that prevent proper functioning of major components and that show up during the preparation for a release. You can also finalize piece of work that is not yet complete, but please avoid merging new features. Note that nightly builds will go on as usual (starting from v6.1.0.1 and going up as usual), and pre-release builds will be available shortly at http://pre-release.racket-lang.org/ Please tell me if you think that this release is significant enough that it should be announced on the users list for wider testing. _ Racket Developers list: http://lists.racket-lang.org/dev
