Re: [racket-dev] Planet 2 Beta Release
On Sat, Dec 8, 2012 at 11:54 PM, Jay McCarthy jay.mccar...@gmail.com wrote: On Sat, Dec 8, 2012 at 9:27 PM, Eli Barzilay e...@barzilay.org wrote: 30 minutes ago, Jay McCarthy wrote: On Sat, Dec 8, 2012 at 8:29 PM, Eli Barzilay e...@barzilay.org wrote: One other thing that I think is important in a migration path is keeping any modification made to the source of the packages that are already installed. Yeah -- and IIUC, the difference between the two installations is where the packages get installed is where the compiled files are, so the sources are the same. At least I *hope* that that's how it is, otherwise it's back to the whole planet cache things, which IMO was a major mistake. They are in the same place. However, I thought the whole premise of this proposed behavior is that the package won't work in the new version of Racket, so certainly the package system can't be responsible for doing a merge your local changes and whatever the updated version of the package needs. I'm not following that -- the compiled files and the sources are in the same place? If so then it makes the whole migration thing kind of impossible with local changes, no? (And I wasn't thinking about merging, just reusing the same sources.) :) Now I'm not following you. If you have a package named P that has a module A/B/C.rkt then on your disk is in: ~/.racket/$version/pkgs/P/A/B/C.rkt with its compiled code in: ~/.racket/$version/pkgs/P/A/B/compiled/C_rkt.zo My idea of raco pkg migrate is just to get a list of the packages that you have installed and re-install them. I think if we assume that Racket versions will break package P then those same problems will prevent you from keeping local changes; especially if the package system isn't responsible for running merge, which it clearly shouldn't be. (Now, I don't think that's a reasonable assumption, i.e. I think version-less should be the default, but I've clearly been out-voted.) First, I still agree with you about version-less being the default. Second, I think an upgradeable installation, replacing the `bin` and `collects` directories, so that migration of packages isn't needed would work better -- that's more like how those of us who use git work, and I think we're mostly happy with that. But even with `migrate`, I think the behavior *needs* to be be 'copy the files, call `setup`'. Otherwise it won't work on a system without the internet, for example. My impression about the reasons for version-specific packages and 'migrate' are that when upgrading, just keeping the same code will potentially error, and so users shouldn't *automatically* keep the same code. But I thought of `migrate` as 'make it seem like those packages were installed for this new installation'. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
On Sun, Dec 9, 2012 at 6:14 AM, Sam Tobin-Hochstadt sa...@ccs.neu.eduwrote: On Sat, Dec 8, 2012 at 11:54 PM, Jay McCarthy jay.mccar...@gmail.com wrote: On Sat, Dec 8, 2012 at 9:27 PM, Eli Barzilay e...@barzilay.org wrote: 30 minutes ago, Jay McCarthy wrote: On Sat, Dec 8, 2012 at 8:29 PM, Eli Barzilay e...@barzilay.org wrote: One other thing that I think is important in a migration path is keeping any modification made to the source of the packages that are already installed. Yeah -- and IIUC, the difference between the two installations is where the packages get installed is where the compiled files are, so the sources are the same. At least I *hope* that that's how it is, otherwise it's back to the whole planet cache things, which IMO was a major mistake. They are in the same place. However, I thought the whole premise of this proposed behavior is that the package won't work in the new version of Racket, so certainly the package system can't be responsible for doing a merge your local changes and whatever the updated version of the package needs. I'm not following that -- the compiled files and the sources are in the same place? If so then it makes the whole migration thing kind of impossible with local changes, no? (And I wasn't thinking about merging, just reusing the same sources.) :) Now I'm not following you. If you have a package named P that has a module A/B/C.rkt then on your disk is in: ~/.racket/$version/pkgs/P/A/B/C.rkt with its compiled code in: ~/.racket/$version/pkgs/P/A/B/compiled/C_rkt.zo My idea of raco pkg migrate is just to get a list of the packages that you have installed and re-install them. I think if we assume that Racket versions will break package P then those same problems will prevent you from keeping local changes; especially if the package system isn't responsible for running merge, which it clearly shouldn't be. (Now, I don't think that's a reasonable assumption, i.e. I think version-less should be the default, but I've clearly been out-voted.) First, I still agree with you about version-less being the default. Second, I think an upgradeable installation, replacing the `bin` and `collects` directories, so that migration of packages isn't needed would work better -- that's more like how those of us who use git work, and I think we're mostly happy with that. But even with `migrate`, I think the behavior *needs* to be be 'copy the files, call `setup`'. Otherwise it won't work on a system without the internet, for example. My impression about the reasons for version-specific packages and 'migrate' are that when upgrading, just keeping the same code will potentially error, and so users shouldn't *automatically* keep the same code. But I thought of `migrate` as 'make it seem like those packages were installed for this new installation'. I don't see any difference between what you're proposing and version-less being default where you type raco setup (or something does it for you) after install. I think that Matthew believes that this won't work because a user may need to get new source code for a package when the Racket version changes, but maybe I've misunderstood his worry. Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
At Sun, 9 Dec 2012 08:14:28 -0500, Sam Tobin-Hochstadt wrote: On Sat, Dec 8, 2012 at 11:54 PM, Jay McCarthy jay.mccar...@gmail.com wrote: My idea of raco pkg migrate is just to get a list of the packages that you have installed and re-install them. Yes, that's what I had in mind. (It may make sense to add an argument to `raco pkg list' to pick a version or to specify the most recent previous version, which could be used by both `raco pkg migrate' and a graphical variant.) Second, I think an upgradeable installation, replacing the `bin` and `collects` directories, so that migration of packages isn't needed would work better -- that's more like how those of us who use git work, and I think we're mostly happy with that. I think this works for us only because we're experts and we know how to patch up the problems. I would never recommend working with a git checkout to a student or new user of Racket. I would never recommend installing a new version on top of an existing version (while I think that installing two different versions to different directories should just work). But even with `migrate`, I think the behavior *needs* to be be 'copy the files, call `setup`'. When was the last time you patched part of your Linux installation and expected the patch to be in place after an upgrade? I know there are people who do that, but I don't think those people use the most popular and friendly distributions, which try to keep installation and maintenance simple. The default has to be the thing that just works. The thing that is best for experienced developers can be one step away from the default --- since experienced developers are, by definition, people who can deal with taking a step away from the default. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
On Wednesday, Sam Tobin-Hochstadt wrote: Given that context, maybe the right thing here is (a) installation- specific packages by default and (b) a way to *upgrade* an existing installation when installing. That might be as simple as automatically running 'raco pkg migrate', but I think making it part of the installation step would make life easier for people, and perhaps an upgrade could avoid duplicating files. I think that this is exactly what Matthew was talking about. One tricky bit here is to know which packages were installed for which level. If *you* installed some packages, then the next time you *run* (not install) an updated racket version you'd be asked if you want to do the migration. But if some package was installed as part of the racket tree (not user specific) then the same question would apply when a new version gets installed. -- ((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 Beta Release
On Dec 8, 2012 10:14 PM, Eli Barzilay e...@barzilay.org wrote: On Wednesday, Sam Tobin-Hochstadt wrote: Given that context, maybe the right thing here is (a) installation- specific packages by default and (b) a way to *upgrade* an existing installation when installing. That might be as simple as automatically running 'raco pkg migrate', but I think making it part of the installation step would make life easier for people, and perhaps an upgrade could avoid duplicating files. I think that this is exactly what Matthew was talking about. One tricky bit here is to know which packages were installed for which level. If *you* installed some packages, then the next time you *run* (not install) an updated racket version you'd be asked if you want to do the migration. But if some package was installed as part of the racket tree (not user specific) then the same question would apply when a new version gets installed. Why would this wait for the first run for any packages? One other thing that I think is important in a migration path is keeping any modification made to the source of the packages that are already installed. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
Just now, Sam Tobin-Hochstadt wrote: On Dec 8, 2012 10:14 PM, Eli Barzilay e...@barzilay.org wrote: I think that this is exactly what Matthew was talking about. One tricky bit here is to know which packages were installed for which level. If *you* installed some packages, then the next time you *run* (not install) an updated racket version you'd be asked if you want to do the migration. But if some package was installed as part of the racket tree (not user specific) then the same question would apply when a new version gets installed. Why would this wait for the first run for any packages? As usual, think about a lab with a central sysadmin-made racket installation. It's impossible to crawl over all users and change stuff in their home directory when the sysadmin upgrades the installation. Now carry this over to OSX and Windows, and it's the same thing. (And even Windows is moving toward a more strict separation between the administrator and plain users.) The thing that makes it somewhat easier there is that the interaction tends to be a single user that plays both roles. So either the user installed some packages for everyone and the upgrade will update those at installation time, or the user installed things for himself, and the upgrade will happen when the new version runs -- usually just after the new installation. One other thing that I think is important in a migration path is keeping any modification made to the source of the packages that are already installed. Yeah -- and IIUC, the difference between the two installations is where the packages get installed is where the compiled files are, so the sources are the same. At least I *hope* that that's how it is, otherwise it's back to the whole planet cache things, which IMO was a major mistake. -- ((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 Beta Release
On Sat, Dec 8, 2012 at 8:29 PM, Eli Barzilay e...@barzilay.org wrote: One other thing that I think is important in a migration path is keeping any modification made to the source of the packages that are already installed. Yeah -- and IIUC, the difference between the two installations is where the packages get installed is where the compiled files are, so the sources are the same. At least I *hope* that that's how it is, otherwise it's back to the whole planet cache things, which IMO was a major mistake. They are in the same place. However, I thought the whole premise of this proposed behavior is that the package won't work in the new version of Racket, so certainly the package system can't be responsible for doing a merge your local changes and whatever the updated version of the package needs. Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
30 minutes ago, Jay McCarthy wrote: On Sat, Dec 8, 2012 at 8:29 PM, Eli Barzilay e...@barzilay.org wrote: One other thing that I think is important in a migration path is keeping any modification made to the source of the packages that are already installed. Yeah -- and IIUC, the difference between the two installations is where the packages get installed is where the compiled files are, so the sources are the same. At least I *hope* that that's how it is, otherwise it's back to the whole planet cache things, which IMO was a major mistake. They are in the same place. However, I thought the whole premise of this proposed behavior is that the package won't work in the new version of Racket, so certainly the package system can't be responsible for doing a merge your local changes and whatever the updated version of the package needs. I'm not following that -- the compiled files and the sources are in the same place? If so then it makes the whole migration thing kind of impossible with local changes, no? (And I wasn't thinking about merging, just reusing the same sources.) -- ((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 Beta Release
On Sun, Dec 2, 2012 at 11:11 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Sun, 2 Dec 2012 10:55:01 -0500, Sam Tobin-Hochstadt wrote: I have mostly the opposite impression of `raco link`. I like the default behavior, but that may be a result of my use of a set of scripts [1] for managing Racket installations that makes basically everything into installation-specific packages. It sounds like you're advocating something that you haven't tried, and you wanted installation-specific links, anyway. I think what's going on here is that we both work in the following style: - a single primary installation from git, upgraded across versions, with frequent version changes, which we want to keep the same set of packages on upgrade - several separate installs from nightly builds or releases, used primarily for testing or for running some single program that remains stable However, we're imagining that most Racket users will use the following style: - a single installation from a release, which is probably removed when upgrading to a new installation of a new version And we're both trying to capture what we like about how we want to work for users with a different style. I see the important feature of my work style as 'packages stay installed when I pull from git', and you see 'when I use a different version, I don't get spurious packages that I didn't wand and don't work'. Does that seem like a fair summary? Given that context, maybe the right thing here is (a) installation-specific packages by default and (b) a way to *upgrade* an existing installation when installing. That might be as simple as automatically running 'raco pkg migrate', but I think making it part of the installation step would make life easier for people, and perhaps an upgrade could avoid duplicating files. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
Given that context, maybe the right thing here is (a) installation-specific packages by default and (b) a way to *upgrade* an existing installation when installing. That might be as simple as automatically running 'raco pkg migrate', but I think making it part of the installation step would make life easier for people, and perhaps an upgrade could avoid duplicating files. I second that. Being a more normal user that most of you, my installation only usually has one version of Racket (in general one of the last nightlies). If you go for the upgrade option, it would be really appreciated if, during installation or on the first run of DrRacket (preferably the former, because of DrRacket Tools), I'm asked whether I want to keep/migrate my packages for the new version. It's currently quite annoying to have to do all this reinstalling by hand. Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
On Sat, Dec 1, 2012 at 10:56 AM, Jay McCarthy jay.mccar...@gmail.com wrote: On Fri, Nov 30, 2012 at 7:09 PM, Matthew Flatt mfl...@cs.utah.edu wrote: Version-specific installation - Not to speak too much on Jay's behalf, but I think he isn't convinced that the new default is right. If `--shared' is the default, then a `raco pkg update' could be enough to get all your installed packages working with a new version. If installation is instead version-specific, then you have to reinstall every package that you use whenever you upgrade. I think that if installation is all-version by default, then users who are going to end up with bad configurations that they have trouble repairing. A better way to deal with upgrades would be something like `raco pkg migrate'. If we decide that version-specific is the right default to keep, and if some would still like a more convenient way to manage all-version packages, we could add an environment variable that makes `--shared' the default. Something that bothers me a lot of P1 is that when I install an upgrade, I lose all my packages. This means that the documentation search suddenly starts returning different things, so I forget about which packages I had installed at all. I only discover this when I go to write something and have a long install and download process. Or, when I run a script I wrote a long time ago and it doesn't return instantly, but spawns an install. I'm much less worried about Racket versions breaking installed packages than Matthew. I don't think it is that common for core changes to break things and when it does happen, P2 is designed to easily allow you to upgrade all your packages to the latest versions, something that was very inconvenient with P1. I.e. you can do raco pkg update --all, which isn't possible with P1. I strongly agree with Jay here. A few additional reasons, besides what he explained: - The explanation that package doesn't work with the latest Racket, you need to update it is easier for people to understand than you don't have that package installed, unless you do in which case you should migrate it to your current version. This is helped by the fact that most other languages that I know of have all-version installation. - Developer convenience is important, and most of us use git HEAD, whose versions change quite rapidly. Now following the version number is very important, otherwise all your software will break. - Once many of the current collects move to packages, there will be many fewer opportunities to break the behavior of the core, so the problems Matthew worries about will be less severe, and the problems Jay and I worry about may be more severe. - Version-specific installation does not work well with package-specific installation, which is something I hope we can add as an option in the future. - One drawback of version-specific installation in Planet1 that I experienced was that fixing an installed Planet package by editing the source broke entirely when switching to a new version. Relatedly, version-specific install almost requires putting the installations in an out-of-the-way directory, making finding and editing source more difficult. -- sam th sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
At Sun, 2 Dec 2012 10:15:56 -0500, Sam Tobin-Hochstadt wrote: - Developer convenience is important, and most of us use git HEAD, whose versions change quite rapidly. Consider installing packages to work with your git HEAD checkout as installation-specific packages. That way, there's no version issue --- and when you want to check Racket's behavior in the current release, your git HEAD build doesn't interfere with the release. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
Who here has tried using `raco link' for development? The default mode is user-specific but not version-specific, and I've found that default to be inconvenient. Usually, it turns out, I want an installation-specific link, because I want it linked only for my development version of Racket. When I get to the point that I do want to use a different Racket version, it's a pain to juggle the links or make a copy for different version. I look forward to using packages, installation-specific links, and version-specific installs that are taken as snapshots of the git repo. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
On Sun, Dec 2, 2012 at 10:38 AM, Matthew Flatt mfl...@cs.utah.edu wrote: Who here has tried using `raco link' for development? I use `raco link` for all of my development -- once `raco link` was released, I basically gave up on Planet1 and used `raco link` for everything. The default mode is user-specific but not version-specific, and I've found that default to be inconvenient. Usually, it turns out, I want an installation-specific link, because I want it linked only for my development version of Racket. When I get to the point that I do want to use a different Racket version, it's a pain to juggle the links or make a copy for different version. I look forward to using packages, installation-specific links, and version-specific installs that are taken as snapshots of the git repo. I have mostly the opposite impression of `raco link`. I like the default behavior, but that may be a result of my use of a set of scripts [1] for managing Racket installations that makes basically everything into installation-specific packages. One additional issue with version-specific installs that I just thought of -- imagine a student installing a course package on a lab computer, and then Racket being upgraded during the semester. [1] https://github.com/takikawa/racket-dev-goodies -- sam th sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
At Sun, 2 Dec 2012 10:55:01 -0500, Sam Tobin-Hochstadt wrote: I have mostly the opposite impression of `raco link`. I like the default behavior, but that may be a result of my use of a set of scripts [1] for managing Racket installations that makes basically everything into installation-specific packages. It sounds like you're advocating something that you haven't tried, and you wanted installation-specific links, anyway. If there's still some reason that environment-variable scripts are the way to go as far as packages are concerned, then let's add an environment variable that changes the default for package installation and affects only people who know how to deal with it. One additional issue with version-specific installs that I just thought of -- imagine a student installing a course package on a lab computer, and then Racket being upgraded during the semester. Exactly. That student is going to get an error message when DrRacket starts up saying that the handin tool is broken. They complain to someone, and so on. It would be much better for the handin tool (for the class they aren't taking anymore) to just be gone until they specifically ask for it back through a migration tool. Or they just shrug and re-install, but that's more obvious and doesn't involve bugging a teacher or admin. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
Exactly. That student is going to get an error message when DrRacket starts up saying that the handin tool is broken. They complain to someone, and so on. Or, even worse, the student can get the error message at Check Syntax time, after which because it's an internal error, DrRacket goes unresponsive and the user can't even save their program anymore. (I've had this happen a few times, and it's one of the worse case scenarios I've run into.) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
On Fri, Nov 30, 2012 at 7:09 PM, Matthew Flatt mfl...@cs.utah.edu wrote: Version-specific installation - Not to speak too much on Jay's behalf, but I think he isn't convinced that the new default is right. If `--shared' is the default, then a `raco pkg update' could be enough to get all your installed packages working with a new version. If installation is instead version-specific, then you have to reinstall every package that you use whenever you upgrade. I think that if installation is all-version by default, then users who are going to end up with bad configurations that they have trouble repairing. A better way to deal with upgrades would be something like `raco pkg migrate'. If we decide that version-specific is the right default to keep, and if some would still like a more convenient way to manage all-version packages, we could add an environment variable that makes `--shared' the default. Something that bothers me a lot of P1 is that when I install an upgrade, I lose all my packages. This means that the documentation search suddenly starts returning different things, so I forget about which packages I had installed at all. I only discover this when I go to write something and have a long install and download process. Or, when I run a script I wrote a long time ago and it doesn't return instantly, but spawns an install. I'm much less worried about Racket versions breaking installed packages than Matthew. I don't think it is that common for core changes to break things and when it does happen, P2 is designed to easily allow you to upgrade all your packages to the latest versions, something that was very inconvenient with P1. I.e. you can do raco pkg update --all, which isn't possible with P1. Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
Yesterday, Matthew Flatt wrote: I've been working with Jay on a few more changes: Specifying metadata --- METADATA.rktd is being replaced with info.rkt, which is written in the `setup/infotab' language as usual. Define `deps' for dependencies, like this: #lang setup/infotab (define deps (list _package-source ...)) For a short transition period (maybe a week?), `raco pkg' will continue to recognize METADATA.rktd. Version-specific installation - Package installation is now both user-specific and version-specific by default. The options are * installation-specific * user-specific and version-specific (the new default) * user-specific and all-version (the old default) Use the `--shared' or `-s' flag to get the old all-version behavior. Any previously installed user-specific packages that you have are still in `--shared' mode. Not to speak too much on Jay's behalf, but I think he isn't convinced that the new default is right. If `--shared' is the default, then a `raco pkg update' could be enough to get all your installed packages working with a new version. If installation is instead version-specific, then you have to reinstall every package that you use whenever you upgrade. I think that if installation is all-version by default, then users who are going to end up with bad configurations that they have trouble repairing. A better way to deal with upgrades would be something like `raco pkg migrate'. Just to see if I get the trade-offs right: all-version installs have the advantage of not re-installing things, and the disadvantage of breaking often (for some value of often)? If so, then something that I think is getting popular is keeping a (global) list of all explicitly installed packages, and then the version-specific installs get much easier to deal with because it's easy to crawl over the explicit names and re-install name. Having this only for explicit names meams that I don't need to reinstall old stuff that was installed only for some other package. (But perhaps this is what you talk about with that `migrate' command. If so, then this is just a verbose +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 Beta Release
Yes, what you describe is what we imagine migrate will do. Jay On Sat, Dec 1, 2012 at 4:10 PM, Eli Barzilay e...@barzilay.org wrote: Yesterday, Matthew Flatt wrote: I've been working with Jay on a few more changes: Specifying metadata --- METADATA.rktd is being replaced with info.rkt, which is written in the `setup/infotab' language as usual. Define `deps' for dependencies, like this: #lang setup/infotab (define deps (list _package-source ...)) For a short transition period (maybe a week?), `raco pkg' will continue to recognize METADATA.rktd. Version-specific installation - Package installation is now both user-specific and version-specific by default. The options are * installation-specific * user-specific and version-specific (the new default) * user-specific and all-version (the old default) Use the `--shared' or `-s' flag to get the old all-version behavior. Any previously installed user-specific packages that you have are still in `--shared' mode. Not to speak too much on Jay's behalf, but I think he isn't convinced that the new default is right. If `--shared' is the default, then a `raco pkg update' could be enough to get all your installed packages working with a new version. If installation is instead version-specific, then you have to reinstall every package that you use whenever you upgrade. I think that if installation is all-version by default, then users who are going to end up with bad configurations that they have trouble repairing. A better way to deal with upgrades would be something like `raco pkg migrate'. Just to see if I get the trade-offs right: all-version installs have the advantage of not re-installing things, and the disadvantage of breaking often (for some value of often)? If so, then something that I think is getting popular is keeping a (global) list of all explicitly installed packages, and then the version-specific installs get much easier to deal with because it's easy to crawl over the explicit names and re-install name. Having this only for explicit names meams that I don't need to reinstall old stuff that was installed only for some other package. (But perhaps this is what you talk about with that `migrate' command. If so, then this is just a verbose +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 -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
A few minutes ago, Robby Findler wrote: I agree. Planet 1 currently does this. Only in drr, where you can see the log... I've seen many people run some random code naively and complain that it does nothing besides spinning the cpu because some packages take a significant time to run. On Friday, November 30, 2012, Eli Barzilay wrote: About three weeks ago, Robby Findler wrote: I would be unhappy, however, if we end up with a system where you have to grovel around in low-level places to get simple uses of uninstalled packages working. That is, I want to be able to put in a blog post or in a talk or somewhere a little program that depends on uninstalled libraries and, if I'm careful about keeping those libraries that the little file works with, then that file should Just Work for casual users who download drracket paste it in, and hit Run. IIUC, there is an API interface for installing packages, so it's possible to write some expression that installs a package if it is not installed. The road from there to a require form that installs something automatically if needed is probably not long, but I think that one main thing that would make things better is if that results in some visible output about the installation that is being done. This avoids the problem of people who think that your random blogged code is not doing anything. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- ((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 Beta Release
Just now, Robby Findler wrote: In DrR, it isn't looking at the log that tells you this, you get a special bar appearing in the window. You don't have to do any extra clicks or anything like that. (Yeah, take that as a generalized version of my see the log...) That said, I don't mind if, when someone runs some planet2 code in racket, outside drracket, that it raises an error saying you need to pass the --slow-me-down-but-automatically-download-missing- packages flag, or just run this program in drracket. WRT the automatic download + install -- while it's obviously possible to do that, I think that because of such things it's generally bad to actually make real code depend on it. Here's what I mean: if you assume that there should always be some visible indication of a package being installed, there is not going to be some magical require that would always work silently, and that can interfere with actually running the code. For example, you do some (require (download-and-install-from-somewhere)) and it might produce some output or it might not -- and the code that uses this might break if there's unexpected output. But such a functionality is obviously useful -- so how about including it only for interactive purposes, which means that you can use it in your blogged code since you know that the extra output is not interfering with your code. If OTOH you post some script for people to run, then you don't use that and instead tell people that they should install the other needed package, and later just pack your own code as a package. This might lead to an interesting direction. Since it's not boring, it might not be a good idea, but still I think that it looks promising... Imagine that there was some meta syntax for required packages (I'll use emacs-like hackish-isms): #lang racket ;; *** Requires: some-package *** ... code ... This idea can be taken further to add more package-like features, eventually like #lang racket ;; *** Package: name-for-this-code-as-a-package *** ;; *** Requires: some-package *** ... code ... which can eventually make it possible to treat a single file as a package. The nice thing that should be obvious now is that there's no need for such hacks, since that require line is serving the same purpose. Except that to really make it possible to do this effectively, you need to be able to know the package information separately for the code -- and submodules look like a perfect way to do that. Just replace the hacks with something like: #lang racket (module pkg planet/pinfo ; for package info or whatever (define package name-for-this-code-as-a-package) (requires some-package) (requires some-other-package and-another)) ... code ... Or drop the define for the shorter case. And since this is still pretty verbose, it might be abstracted away in some macro. (But I don't remember the dependency issues with such things, so it might not be doable as is.) I think that with something like that you can get everything that you want. A plain run in drr can do the same thing when it sees that there's a package inforation. Toplevel requires in the racket input can do the same, but just requiring this file from another will not do it which means that you can also use it this way without worrying about interfering with real runs. And you can also have some new command like raco pkg install-whatever-is-needed-for some-file.rkt which would be like doing the toplevel require thing. -- ((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 Beta Release
About three weeks ago, Jay McCarthy wrote: On Thu, Nov 8, 2012 at 1:48 PM, Eli Barzilay e...@barzilay.org wrote: 20 minutes ago, Jay McCarthy wrote: I have no preference about this shed color. If others feel strongly, it can change. I do. It would be better IMO to look at existing packagers and reuse some of their conventions. (I know that at least the chrome packages have similar things, and I liked their design.) I based the convention off CPAN with its META.yml file. I think that CPAN is old enough to not be a good role model... It should be possible to distribute the separate parts regardless of where they are. The thing is that with a single directory management of code is much easier. Eventually, many of the collections in the current tree should move out into their own repositories. In any case, I've missed it and will make the change to the recommendations, although personally I like having separate directories like tests because it doesn't clutter my main code directory. I think that a separate repository is a good thing to consider here: you obviously need to clutter your repo with tests and documentation. -- ((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 Beta Release
In DrR, it isn't looking at the log that tells you this, you get a special bar appearing in the window. You don't have to do any extra clicks or anything like that. That said, I don't mind if, when someone runs some planet2 code in racket, outside drracket, that it raises an error saying you need to pass the --slow-me-down-but-automatically-download-missing-packages flag, or just run this program in drracket. Robby On Fri, Nov 30, 2012 at 8:44 AM, Eli Barzilay e...@barzilay.org wrote: A few minutes ago, Robby Findler wrote: I agree. Planet 1 currently does this. Only in drr, where you can see the log... I've seen many people run some random code naively and complain that it does nothing besides spinning the cpu because some packages take a significant time to run. On Friday, November 30, 2012, Eli Barzilay wrote: About three weeks ago, Robby Findler wrote: I would be unhappy, however, if we end up with a system where you have to grovel around in low-level places to get simple uses of uninstalled packages working. That is, I want to be able to put in a blog post or in a talk or somewhere a little program that depends on uninstalled libraries and, if I'm careful about keeping those libraries that the little file works with, then that file should Just Work for casual users who download drracket paste it in, and hit Run. IIUC, there is an API interface for installing packages, so it's possible to write some expression that installs a package if it is not installed. The road from there to a require form that installs something automatically if needed is probably not long, but I think that one main thing that would make things better is if that results in some visible output about the installation that is being done. This avoids the problem of people who think that your random blogged code is not doing anything. -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! -- ((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 Beta Release
Yes, I think we're roughly on the same page. Printing is a bad idea when installing, but logging seems fine and that is how drracket can detect it should update the GUI to let people know that something is being installed. And a command-line flag (that perhaps translates to some setting on the namespace that is derived from a parameter) can determine if installing packages is allowed or not. I think all this is doable and I think we can get something that keeps the kiss principle and make things just work in common situations without sacrificing security or whathaveyou. Robby On Fri, Nov 30, 2012 at 10:38 AM, Eli Barzilay e...@barzilay.org wrote: Just now, Robby Findler wrote: In DrR, it isn't looking at the log that tells you this, you get a special bar appearing in the window. You don't have to do any extra clicks or anything like that. (Yeah, take that as a generalized version of my see the log...) That said, I don't mind if, when someone runs some planet2 code in racket, outside drracket, that it raises an error saying you need to pass the --slow-me-down-but-automatically-download-missing- packages flag, or just run this program in drracket. WRT the automatic download + install -- while it's obviously possible to do that, I think that because of such things it's generally bad to actually make real code depend on it. Here's what I mean: if you assume that there should always be some visible indication of a package being installed, there is not going to be some magical require that would always work silently, and that can interfere with actually running the code. For example, you do some (require (download-and-install-from-somewhere)) and it might produce some output or it might not -- and the code that uses this might break if there's unexpected output. But such a functionality is obviously useful -- so how about including it only for interactive purposes, which means that you can use it in your blogged code since you know that the extra output is not interfering with your code. If OTOH you post some script for people to run, then you don't use that and instead tell people that they should install the other needed package, and later just pack your own code as a package. This might lead to an interesting direction. Since it's not boring, it might not be a good idea, but still I think that it looks promising... Imagine that there was some meta syntax for required packages (I'll use emacs-like hackish-isms): #lang racket ;; *** Requires: some-package *** ... code ... This idea can be taken further to add more package-like features, eventually like #lang racket ;; *** Package: name-for-this-code-as-a-package *** ;; *** Requires: some-package *** ... code ... which can eventually make it possible to treat a single file as a package. The nice thing that should be obvious now is that there's no need for such hacks, since that require line is serving the same purpose. Except that to really make it possible to do this effectively, you need to be able to know the package information separately for the code -- and submodules look like a perfect way to do that. Just replace the hacks with something like: #lang racket (module pkg planet/pinfo ; for package info or whatever (define package name-for-this-code-as-a-package) (requires some-package) (requires some-other-package and-another)) ... code ... Or drop the define for the shorter case. And since this is still pretty verbose, it might be abstracted away in some macro. (But I don't remember the dependency issues with such things, so it might not be doable as is.) I think that with something like that you can get everything that you want. A plain run in drr can do the same thing when it sees that there's a package inforation. Toplevel requires in the racket input can do the same, but just requiring this file from another will not do it which means that you can also use it this way without worrying about interfering with real runs. And you can also have some new command like raco pkg install-whatever-is-needed-for some-file.rkt which would be like doing the toplevel require thing. -- ((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 Beta Release
At Fri, 30 Nov 2012 09:00:55 -0500, Eli Barzilay wrote: Yesterday, Asumu Takikawa wrote: On 2012-11-29 06:52:07 -0700, Matthew Flatt wrote: raco pkg install fish-tank/ This is nice, I've been confused by the old behavior before. I don't think that this is a good idea -- since it's a hook onto a syntax of directory names which conflicts with the common convention that dir/ is the same as dir. One random example where this can be a problem is zsh directory completions -- with my setup (and this is a zsh feature that is used by many people) if I have a fish-tank directory and I type rack pkg install fish-TAB I get zsh to complete that and get rack pkg install fish-tank/ and if at this point I hit enter, zsh will *remove* that slash and then run the command: rack pkg install fish-tank A slightly better convention for directory names is ./fish-tank -- but that convention is useful for cases where a string can be interpreted as either a local path or something else (like a flag) and I want to force the path interpretation. IOW, it fits a mode of work where there is some dynamic interpretation based on the existence of a directory or a known package name, with a way to force the former. Good point, and the ./ does prevent the path from being interpreted as a package name. I'll change this. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
I've been working with Jay on a few more changes: Specifying metadata --- METADATA.rktd is being replaced with info.rkt, which is written in the `setup/infotab' language as usual. Define `deps' for dependencies, like this: #lang setup/infotab (define deps (list _package-source ...)) For a short transition period (maybe a week?), `raco pkg' will continue to recognize METADATA.rktd. Version-specific installation - Package installation is now both user-specific and version-specific by default. The options are * installation-specific * user-specific and version-specific (the new default) * user-specific and all-version (the old default) Use the `--shared' or `-s' flag to get the old all-version behavior. Any previously installed user-specific packages that you have are still in `--shared' mode. Not to speak too much on Jay's behalf, but I think he isn't convinced that the new default is right. If `--shared' is the default, then a `raco pkg update' could be enough to get all your installed packages working with a new version. If installation is instead version-specific, then you have to reinstall every package that you use whenever you upgrade. I think that if installation is all-version by default, then users who are going to end up with bad configurations that they have trouble repairing. A better way to deal with upgrades would be something like `raco pkg migrate'. If we decide that version-specific is the right default to keep, and if some would still like a more convenient way to manage all-version packages, we could add an environment variable that makes `--shared' the default. Setup after installation Previously, `raco pkg install' would run the equivalent of `raco setup' with no arguments after installing packages. Now, `raco pkg install' runs the equivalent of `raco setup collection ...', where the collections are all the ones represented installed packages, plus scribblings/main/user and/or scribblings/main. To control the set of collections added to `raco setup' for a package, define `setup-collects' in the package's info.rkt. Use 'all to get the old behavior (i.e., global setup) back. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
I've pushed a few changes in consultation with Jay. The changes are small, so far, but the most prominent change is that the interpretation of a package source is now determined syntactically. If you want to install from a local directory fish-tank, you need to write raco pkg install fish-tank/ or raco pkg install --type dir fish-tank because raco pkg install fish-tank will always contact the package name service to try to resolve fish-tank. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
On 2012-11-29 06:52:07 -0700, Matthew Flatt wrote: The changes are small, so far, but the most prominent change is that the interpretation of a package source is now determined syntactically. If you want to install from a local directory fish-tank, you need to write raco pkg install fish-tank/ This is nice, I've been confused by the old behavior before. One thing that doesn't work (in either the old or current setup) is paths with . or ..: raco pkg install ./ raco pkg install ../ Also, is there any reason why the `update` command can't work with packages from local directories? Or should I just use --link for these cases? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
On Thu, Nov 29, 2012 at 1:23 PM, Asumu Takikawa as...@ccs.neu.edu wrote: On 2012-11-29 06:52:07 -0700, Matthew Flatt wrote: The changes are small, so far, but the most prominent change is that the interpretation of a package source is now determined syntactically. If you want to install from a local directory fish-tank, you need to write raco pkg install fish-tank/ This is nice, I've been confused by the old behavior before. One thing that doesn't work (in either the old or current setup) is paths with . or ..: raco pkg install ./ raco pkg install ../ Also, is there any reason why the `update` command can't work with packages from local directories? It assumes that the directory won't be there anymore... I guess that's a bad assumption. Or should I just use --link for these cases? That is my suggestion to developers. I think all installed packages should be either local links or named by the naming service. All the other package source modes are for people doing creative things, like maintaining their own sets of packages for deployments, etc. Jay Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
On 2012-11-29 13:28:03 -0700, Jay McCarthy wrote: That is my suggestion to developers. I think all installed packages should be either local links or named by the naming service. All the other package source modes are for people doing creative things, like maintaining their own sets of packages for deployments, etc. Could --link be the default for local directory packages then? Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
On Mon, Nov 12, 2012 at 2:15 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Thu, Nov 8, 2012 at 7:44 PM, Robby Findler ro...@eecs.northwestern.edu wrote: On Thu, Nov 8, 2012 at 3:44 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Thu, Nov 8, 2012 at 3:13 PM, Jay McCarthy jay.mccar...@gmail.com wrote: On Thu, Nov 8, 2012 at 11:01 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: * I think the auto-installing module resolver mentioned in Short Term is a bad idea -- it's already really easy to install packages with this system, and auto-installation just introduces possibility for headaches. I don't think it is *bad* idea, but I also don't think it is *necessary*. But there are other people in the Racket group who think this is totally necessary for Planet 2. I'll let them explain why. I'll look forward to that explanation. I think it is important that you can get a program from the web, put it into DrRacket, hit run, and get Something Good to happen, without having to go type at command lines and whatnot. (This is especially true for Windows, the platform something like 95% of our users use.) I agree entirely that we need a non-command-line way of installing packages, and we should provide a GUI for handling that in DrRacket. I think that the percentage of our users that install new packages is much less Windows-heavy than the overall user base. I think a system where DrRacket can, in some modes, prompt the user to install packages would be a big improvement over automatic installation. Right now, running a file can trigger automatic installation of arbitrary numbers of packages, some of which then conflict or which have errors that the user can't be expected to understand. This is even worse when the user didn't know anything about the packages being installed. That's what I'm proposing as the default, btw. Jay Sam -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
On Thu, Nov 8, 2012 at 1:01 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: I have one larger design issue, which I want to write up in a separate mail. The larger issue is that we should allow packages to have their own versions of other packages/collections/etc, specified in their metadata file. This would be less ambitious than what Planet1 does, where a single running Racket program can have two copies of the same planet package, but would let the programmer handle situations where conflicts exist. Here's an example: package A depends on package B. I want to use package A in my program P, but I need it to use a fixed version of package B. However, I don't want to make a global change to the state of my planet cache. So in my `package.rktd` file for P, I specify that B should be obtained from my fork of B on GitHub. This change is self-contained, and doesn't require changes to any of the rest of the system. This is how the node.js package manager NPM works. It implies that most node.js programs have a full copy of their dependencies in their installation directory -- they in general avoid global installation. I'm not sure we should go that far, but I think making it possible is very useful. I know people who've had exactly the situation in my example, which they worked around using this capability of NPM. I'm not sure this can be done purely by Planet2, it may require more capabilities from Racket, probably in changing how the links data is specified. -- sam th sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
I expect we can do a better job in planet2 than we are doing in planet1 and I am in favor of trying to find that balance. I would be unhappy, however, if we end up with a system where you have to grovel around in low-level places to get simple uses of uninstalled packages working. That is, I want to be able to put in a blog post or in a talk or somewhere a little program that depends on uninstalled libraries and, if I'm careful about keeping those libraries that the little file works with, then that file should Just Work for casual users who download drracket paste it in, and hit Run. I not mean to imply we do things just the way planet1 does them. Only that we find a way for things to just work for casual users. I realize that this is a hard design problem and that's why I think we should be thinking about it early. Hopefully my underlying desire is not to contentious! Robby On Monday, November 12, 2012, Sam Tobin-Hochstadt wrote: On Thu, Nov 8, 2012 at 7:44 PM, Robby Findler ro...@eecs.northwestern.edu javascript:; wrote: On Thu, Nov 8, 2012 at 3:44 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edujavascript:; wrote: On Thu, Nov 8, 2012 at 3:13 PM, Jay McCarthy jay.mccar...@gmail.comjavascript:; wrote: On Thu, Nov 8, 2012 at 11:01 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu javascript:; wrote: * I think the auto-installing module resolver mentioned in Short Term is a bad idea -- it's already really easy to install packages with this system, and auto-installation just introduces possibility for headaches. I don't think it is *bad* idea, but I also don't think it is *necessary*. But there are other people in the Racket group who think this is totally necessary for Planet 2. I'll let them explain why. I'll look forward to that explanation. I think it is important that you can get a program from the web, put it into DrRacket, hit run, and get Something Good to happen, without having to go type at command lines and whatnot. (This is especially true for Windows, the platform something like 95% of our users use.) I agree entirely that we need a non-command-line way of installing packages, and we should provide a GUI for handling that in DrRacket. I think that the percentage of our users that install new packages is much less Windows-heavy than the overall user base. I think a system where DrRacket can, in some modes, prompt the user to install packages would be a big improvement over automatic installation. Right now, running a file can trigger automatic installation of arbitrary numbers of packages, some of which then conflict or which have errors that the user can't be expected to understand. This is even worse when the user didn't know anything about the packages being installed. Sam _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
Thanks, Jay! This is great news. After my dissertation defense next week, I imagine I'll be putting Planet 2 to the test. Carl Eastlund On Thu, Nov 8, 2012 at 8:16 AM, Jay McCarthy jay.mccar...@gmail.com wrote: Now that the 5.3.1 release is finished, I've just pushed the beta release of Planet 2 to the Racket core. I've tried to answer all questions and explain everything about Planet 2 in the documentation, which I've uploaded a copy of here: http://faculty.cs.byu.edu/~jay/tmp/20121108-pkgs/planet2/index.html In particular, it explains what the plan is to go from this beta release to the final release. If you currently have packages on Planet 1, I am excited to help you make the transition to Planet 2. (I am currently in the process of converting my packages.) Please do not hesitate to let me know how I can help. This represents the third iteration of the design of Planet 2. (The first was worked on from August 10, 2010 to March 11, 2011. The second in July 2011. The third from August 2011 until now, although coding didn't begin until December 2011.) Enjoy, Jay p.s. In the implementation, I'm particularly proud of the little language for defining command-line interfaces with matching functions (see planet2/main.rkt for a use) and the testing infrastructure that allows you to run sequences of shell commands and check their output (see tests/planet2/tests-install.rkt for a nice example.) -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
Huge!!! The manual deployment at first glance appears to allow the use of the various cloud drives as deployment options. Drop a x.plt file onto Amazon S3, or Google GDrive or Ubuntu One, which are for all intents and purposes essentially free, make it publicly accessible and announce the URL. And Git support, thank you. Planet2 will be key to community growth. On Thu, Nov 8, 2012 at 8:16 AM, Jay McCarthy jay.mccar...@gmail.com wrote: Now that the 5.3.1 release is finished, I've just pushed the beta release of Planet 2 to the Racket core. I've tried to answer all questions and explain everything about Planet 2 in the documentation, which I've uploaded a copy of here: http://faculty.cs.byu.edu/~jay/tmp/20121108-pkgs/planet2/index.html In particular, it explains what the plan is to go from this beta release to the final release. If you currently have packages on Planet 1, I am excited to help you make the transition to Planet 2. (I am currently in the process of converting my packages.) Please do not hesitate to let me know how I can help. This represents the third iteration of the design of Planet 2. (The first was worked on from August 10, 2010 to March 11, 2011. The second in July 2011. The third from August 2011 until now, although coding didn't begin until December 2011.) Enjoy, Jay p.s. In the implementation, I'm particularly proud of the little language for defining command-line interfaces with matching functions (see planet2/main.rkt for a use) and the testing infrastructure that allows you to run sequences of shell commands and check their output (see tests/planet2/tests-install.rkt for a nice example.) -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
Yup, that's the idea. Although I imagine most people will find Github the best option since you don't need to anything you aren't already doing. (That is, the manual option requires you to do raco create and then upload the file, whereas when you use Github you always git push anyways.) On Thu, Nov 8, 2012 at 8:49 AM, Ray Racine ray.rac...@gmail.com wrote: Huge!!! The manual deployment at first glance appears to allow the use of the various cloud drives as deployment options. Drop a x.plt file onto Amazon S3, or Google GDrive or Ubuntu One, which are for all intents and purposes essentially free, make it publicly accessible and announce the URL. And Git support, thank you. Planet2 will be key to community growth. On Thu, Nov 8, 2012 at 8:16 AM, Jay McCarthy jay.mccar...@gmail.com wrote: Now that the 5.3.1 release is finished, I've just pushed the beta release of Planet 2 to the Racket core. I've tried to answer all questions and explain everything about Planet 2 in the documentation, which I've uploaded a copy of here: http://faculty.cs.byu.edu/~jay/tmp/20121108-pkgs/planet2/index.html In particular, it explains what the plan is to go from this beta release to the final release. If you currently have packages on Planet 1, I am excited to help you make the transition to Planet 2. (I am currently in the process of converting my packages.) Please do not hesitate to let me know how I can help. This represents the third iteration of the design of Planet 2. (The first was worked on from August 10, 2010 to March 11, 2011. The second in July 2011. The third from August 2011 until now, although coding didn't begin until December 2011.) Enjoy, Jay p.s. In the implementation, I'm particularly proud of the little language for defining command-line interfaces with matching functions (see planet2/main.rkt for a use) and the testing infrastructure that allows you to run sequences of shell commands and check their output (see tests/planet2/tests-install.rkt for a nice example.) -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
On 11/08/2012 06:16 AM, Jay McCarthy wrote: Now that the 5.3.1 release is finished, I've just pushed the beta release of Planet 2 to the Racket core. I just read the docs. This is friggin' awesome. Neil ⊥ _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
On Thu, Nov 8, 2012 at 10:12 AM, Neil Toronto neil.toro...@gmail.comwrote: On 11/08/2012 06:16 AM, Jay McCarthy wrote: Now that the 5.3.1 release is finished, I've just pushed the beta release of Planet 2 to the Racket core. I just read the docs. This is friggin' awesome. Quick comment: the install instructions should not be shown with hover. Here's why: I view the page for a package. Cool, new package. Let me open up DrRacket. Oh, wait, my window focus isn't over that link anymore, so I can't see the install instructions. :) What about putting the install instructions in the right margin, similar to a margin-note? _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
On 2012-11-08 06:16:58 -0700, Jay McCarthy wrote: Now that the 5.3.1 release is finished, I've just pushed the beta release of Planet 2 to the Racket core. Very nice! I'll provide some feedback once I've tried to port a package. BTW, I get an exception when I click Log in on this page with blank fields: https://plt-etc.byu.edu:9004/manage/upload build-path: path element is an empty string argument position: 2nd other arguments...: #path:/home/plt-etc/local/galaxy/meta/planet2-index/official/root/users Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
On Thu, Nov 8, 2012 at 1:35 PM, Eli Barzilay e...@barzilay.org wrote: * We really need valid SSL certificates for any user-facing sites. StartSSL gives them away for free: http://www.startssl.com/ (Last time I looked, free SSLs weren't ones that would get trusted by default popular browsers. If you're talking about some certificate, then making them is easy.) This is not correct -- StartSSL is in the trust root for major browsers. See http://en.wikipedia.org/wiki/StartCom for details, which I confirmed on Firefox. -- sam th sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
On Thu, Nov 8, 2012 at 11:01 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Thu, Nov 8, 2012 at 8:16 AM, Jay McCarthy jay.mccar...@gmail.com wrote: Now that the 5.3.1 release is finished, I've just pushed the beta release of Planet 2 to the Racket core. Here, as promised, more detailed but small comments. I have one larger design issue, which I want to write up in a separate mail. * I think the places you use 'PLT' in the documentation should be replace with 'Racket maintainers' -- PLT is a research group with lots of overlap with the Racket maintainers. Sure. * I think tying to GitHub is a mistake -- the system should work for for arbitrary Git repositories. Having a short syntax for github is great, though. Additionally, we should support fixing a checksum for a package. The npm docs have a similar list of things that can be installed here: https://npmjs.org/doc/install.html Github automatically generates zip/tgz files. Planet 2 knows nothing about Github other than this and the URL structure of their site to get them and the checksums. If you'd like to implement general git support, I think that would be great, but it is more work than I have time to do. I can point you in the right direction. * I think we should drop the `.plt` archive format entirely. It is the default because Racket can create it and unarchive it natively. If someone implements a native Racket zipper/unzipper, that would be great. My understanding is that this is on Eli's todo list and when it is done, it would be great to change Planet 2's default. * It would be nice to have a command-line way of publishing a package to a name service. I don't want to legislate how that works, force all service to support publishing, or reimplement the pieces of the Web browser that submit the forms, etc. Additionally, I expect you do this rarely. * I think use 'dont-' in command line arguments is potentially confusing, and the 'no-' prefix is more common in other software. I have no preference about this shed color. If others feel strongly, it can change. * It would be nice to have fewer special files. For example, `MANIFEST` could be abolished by just fetching the whole content of the directory. Checksums could be included in the `METADATA` file. The manifest is necessary because there's no reliable way to get a directory list from a Web site. The checksum can't be in the metadata because the metadata is in the archive, but you need to be able to get the checksum without getting the archive. * Similarly, the names of the special files could avoid ALL-CAPS, and I'd go with the name 'package' rather than `metadata`. I have no preference about this shed color. If others feel strongly, it can change. * I think 'update' with no arguments shouldn't do a global operation; use `-a/--all` for that, otherwise it's easy (say in scripts) to accidentally trigger the global behavior. I'll make this change soon. * In section 3.1, you should have 'git push -u origin master'. This is directly from the Github docs: https://help.github.com/articles/create-a-repo * We really need valid SSL certificates for any user-facing sites. StartSSL gives them away for free: http://www.startssl.com/ I agree that the Racket maintainers should buy something like this. * I thought the conclusion of a recent discussion on dev@ was that tests, typed, etc sub-collections *are* preferred. I think I missed this conversation. I don't understand the conclusion given that we don't want to always distribute tests, for example. * Can the Planet1 compatibility also have a version-less translation for the latest version, so that `jaymccarthy/opencl/module` could keep working? I don't want that version-less one to conflict with any of the other ones so that Planet 1 packages that rely on multiple versions will work. Am I missing a part of the request? * I think the auto-installing module resolver mentioned in Short Term is a bad idea -- it's already really easy to install packages with this system, and auto-installation just introduces possibility for headaches. I don't think it is *bad* idea, but I also don't think it is *necessary*. But there are other people in the Racket group who think this is totally necessary for Planet 2. I'll let them explain why. Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
20 minutes ago, Jay McCarthy wrote: * I think tying to GitHub is a mistake -- the system should work for for arbitrary Git repositories. Having a short syntax for github is great, though. Additionally, we should support fixing a checksum for a package. The npm docs have a similar list of things that can be installed here: https://npmjs.org/doc/install.html Github automatically generates zip/tgz files. Planet 2 knows nothing about Github other than this and the URL structure of their site to get them and the checksums. This is something that many (probably all) git places do -- and even the gitweb script that we're using on git.racket-lang.org knows how to do. (See the zip and tar.gz links.) In any case, since this is just a URL format thing, it should be easy to put it in some place that could be easily extended for other places, and possibly pluggable. If you'd like to implement general git support, I think that would be great, but it is more work than I have time to do. I can point you in the right direction. If you have a git command, then it's a simple matter of using git archive. There's some robust git looking in the repo-time-stamp collection that could be lifted up for this. * I think we should drop the `.plt` archive format entirely. It is the default because Racket can create it and unarchive it natively. If someone implements a native Racket zipper/unzipper, that would be great. My understanding is that this is on Eli's todo list and when it is done, it would be great to change Planet 2's default. How about requiring a format for now, to avoid changing the default later? The checksum can't be in the metadata because the metadata is in the archive, but you need to be able to get the checksum without getting the archive. (Is the checksum only needed for detecting updates? If so, then why not use just the timestamp?) * Similarly, the names of the special files could avoid ALL-CAPS, and I'd go with the name 'package' rather than `metadata`. I have no preference about this shed color. If others feel strongly, it can change. I do. It would be better IMO to look at existing packagers and reuse some of their conventions. (I know that at least the chrome packages have similar things, and I liked their design.) * In section 3.1, you should have 'git push -u origin master'. This is directly from the Github docs: https://help.github.com/articles/create-a-repo Using -u is much better. The reason it is not in the github page is possibly that they're aiming at ancient git versions that didn't have it. (IIRC, when we migrated to git this option was new, and should be safe to assume that everyone has it now...) (Also, I'm not sure how well they maintain those help pages -- they had a few more educational projects since we migrated, and recently there's something even more ambitious.) * I thought the conclusion of a recent discussion on dev@ was that tests, typed, etc sub-collections *are* preferred. I think I missed this conversation. I don't understand the conclusion given that we don't want to always distribute tests, for example. It should be possible to distribute the separate parts regardless of where they are. The thing is that with a single directory management of code is much easier. Eventually, many of the collections in the current tree should move out into their own repositories. -- ((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 Beta Release
30 minutes ago, Jay McCarthy wrote: IIUC, the branch in the path is required, is that the case? If so, then I think that it should really work without it too, to get the simple https://github.com/user/repo syntax. Yes it is required. We could do that, right now there's not assumptions like this (i.e. you always want master) anywhere else in the system so I didn't do it. I think that such assumptions are very common, especially in the github world. Since it's still just a URL thing and it's easy to add, I think that GH users would expect it to work. -- ((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 Beta Release
On Thu, Nov 8, 2012 at 1:48 PM, Eli Barzilay e...@barzilay.org wrote: 20 minutes ago, Jay McCarthy wrote: * I think tying to GitHub is a mistake -- the system should work for for arbitrary Git repositories. Having a short syntax for github is great, though. Additionally, we should support fixing a checksum for a package. The npm docs have a similar list of things that can be installed here: https://npmjs.org/doc/install.html Github automatically generates zip/tgz files. Planet 2 knows nothing about Github other than this and the URL structure of their site to get them and the checksums. This is something that many (probably all) git places do -- and even the gitweb script that we're using on git.racket-lang.org knows how to do. (See the zip and tar.gz links.) In any case, since this is just a URL format thing, it should be easy to put it in some place that could be easily extended for other places, and possibly pluggable. I'm fine with that... but I don't have the bandwidth to develop it for anything I don't use. If you'd like to implement general git support, I think that would be great, but it is more work than I have time to do. I can point you in the right direction. If you have a git command, then it's a simple matter of using git archive. There's some robust git looking in the repo-time-stamp collection that could be lifted up for this. Yes I was going to that first, but (a) I didn't want to rely on the git command and (b) github doesn't support git archive. * I think we should drop the `.plt` archive format entirely. It is the default because Racket can create it and unarchive it natively. If someone implements a native Racket zipper/unzipper, that would be great. My understanding is that this is on Eli's todo list and when it is done, it would be great to change Planet 2's default. How about requiring a format for now, to avoid changing the default later? I'll do that. The checksum can't be in the metadata because the metadata is in the archive, but you need to be able to get the checksum without getting the archive. (Is the checksum only needed for detecting updates? If so, then why not use just the timestamp?) The checksum is just a string, with no interpretation, you could use a timestamp as yours. In the case of github though, I can easily get the checksum but not a timestamp. * Similarly, the names of the special files could avoid ALL-CAPS, and I'd go with the name 'package' rather than `metadata`. I have no preference about this shed color. If others feel strongly, it can change. I do. It would be better IMO to look at existing packagers and reuse some of their conventions. (I know that at least the chrome packages have similar things, and I liked their design.) I based the convention off CPAN with its META.yml file. * In section 3.1, you should have 'git push -u origin master'. This is directly from the Github docs: https://help.github.com/articles/create-a-repo Using -u is much better. The reason it is not in the github page is possibly that they're aiming at ancient git versions that didn't have it. (IIRC, when we migrated to git this option was new, and should be safe to assume that everyone has it now...) (Also, I'm not sure how well they maintain those help pages -- they had a few more educational projects since we migrated, and recently there's something even more ambitious.) Changed. * I thought the conclusion of a recent discussion on dev@ was that tests, typed, etc sub-collections *are* preferred. I think I missed this conversation. I don't understand the conclusion given that we don't want to always distribute tests, for example. It should be possible to distribute the separate parts regardless of where they are. The thing is that with a single directory management of code is much easier. Eventually, many of the collections in the current tree should move out into their own repositories. In any case, I've missed it and will make the change to the recommendations, although personally I like having separate directories like tests because it doesn't clutter my main code directory. Jay -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
On Thu, Nov 8, 2012 at 3:13 PM, Jay McCarthy jay.mccar...@gmail.com wrote: On Thu, Nov 8, 2012 at 11:01 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: [replying just to a few of these] * I think we should drop the `.plt` archive format entirely. It is the default because Racket can create it and unarchive it natively. If someone implements a native Racket zipper/unzipper, that would be great. My understanding is that this is on Eli's todo list and when it is done, it would be great to change Planet 2's default. Hopefully this can happen before Planet 2's release, so it wouldn't need to support .plt at all. * It would be nice to have fewer special files. For example, `MANIFEST` could be abolished by just fetching the whole content of the directory. Checksums could be included in the `METADATA` file. The manifest is necessary because there's no reliable way to get a directory list from a Web site. Then I would just suggest dropping the web-directory fetching instead, and just support archives at URLs. * In section 3.1, you should have 'git push -u origin master'. This is directly from the Github docs: https://help.github.com/articles/create-a-repo If you create a fresh repo on GH, you get instructions with the `-u` option -- I'm surprised that they haven't updated the help site. * I thought the conclusion of a recent discussion on dev@ was that tests, typed, etc sub-collections *are* preferred. I think I missed this conversation. I don't understand the conclusion given that we don't want to always distribute tests, for example. This discussion was here: http://lists.racket-lang.org/dev/archive/2012-October/010507.html I'm not sure there was a definitive conclusion, but Robby/Eli/Matthias seems to be on the sub-collection side. * Can the Planet1 compatibility also have a version-less translation for the latest version, so that `jaymccarthy/opencl/module` could keep working? I don't want that version-less one to conflict with any of the other ones so that Planet 1 packages that rely on multiple versions will work. Am I missing a part of the request? I'm just suggesting that `../opencl` and `.../opencl1` should both exist. * I think the auto-installing module resolver mentioned in Short Term is a bad idea -- it's already really easy to install packages with this system, and auto-installation just introduces possibility for headaches. I don't think it is *bad* idea, but I also don't think it is *necessary*. But there are other people in the Racket group who think this is totally necessary for Planet 2. I'll let them explain why. I'll look forward to that explanation. -- sam th sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
Just out of curiosity: What are your / the teams objections against some kind of real versioning system that allows to * specify a version number without creating a new package * specify dependencies based on minimal version * keep/pin a package at some particular version (maybe your code depends on an exact, even buggy behavior) * keep directory and file names between incompatible versions without getting banned from solar What made me also wonder when i read the docs is, why is it allowed to have packets that have the same directories as the core racket distribution? Tobias On Thu, 08 Nov 2012 14:16:58 +0100, Jay McCarthy jay.mccar...@gmail.com wrote: Now that the 5.3.1 release is finished, I've just pushed the beta release of Planet 2 to the Racket core. I've tried to answer all questions and explain everything about Planet 2 in the documentation, which I've uploaded a copy of here: http://faculty.cs.byu.edu/~jay/tmp/20121108-pkgs/planet2/index.html In particular, it explains what the plan is to go from this beta release to the final release. If you currently have packages on Planet 1, I am excited to help you make the transition to Planet 2. (I am currently in the process of converting my packages.) Please do not hesitate to let me know how I can help. This represents the third iteration of the design of Planet 2. (The first was worked on from August 10, 2010 to March 11, 2011. The second in July 2011. The third from August 2011 until now, although coding didn't begin until December 2011.) Enjoy, Jay p.s. In the implementation, I'm particularly proud of the little language for defining command-line interfaces with matching functions (see planet2/main.rkt for a use) and the testing infrastructure that allows you to run sequences of shell commands and check their output (see tests/planet2/tests-install.rkt for a nice example.) _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
The original Planet had explicit rules for versions, and in practice I found they got in the way almost as often as they helped. Worse, when they did get in the way, there was no way around them. I have not looked at Planet 2 in detail yet, but it looks like it has a simpler model where versions are dealt with directly by maintainers and clients. So while Planet 2 isn't doing the work for you, it's also not keeping you from doing what you want/need to do. This isn't ideal -- I'd really like a system that does all the nice things you mention, Tobias -- but only once someone has a design that really gets it right. Until then, I'd much rather have my options open and a system that stays out of my way. Carl Eastlund On Thu, Nov 8, 2012 at 5:22 PM, Tobias Hammer tobias.ham...@dlr.de wrote: Just out of curiosity: What are your / the teams objections against some kind of real versioning system that allows to * specify a version number without creating a new package * specify dependencies based on minimal version * keep/pin a package at some particular version (maybe your code depends on an exact, even buggy behavior) * keep directory and file names between incompatible versions without getting banned from solar What made me also wonder when i read the docs is, why is it allowed to have packets that have the same directories as the core racket distribution? Tobias On Thu, 08 Nov 2012 14:16:58 +0100, Jay McCarthy jay.mccar...@gmail.com wrote: Now that the 5.3.1 release is finished, I've just pushed the beta release of Planet 2 to the Racket core. I've tried to answer all questions and explain everything about Planet 2 in the documentation, which I've uploaded a copy of here: http://faculty.cs.byu.edu/~**jay/tmp/20121108-pkgs/planet2/**index.htmlhttp://faculty.cs.byu.edu/%7Ejay/tmp/20121108-pkgs/planet2/index.html In particular, it explains what the plan is to go from this beta release to the final release. If you currently have packages on Planet 1, I am excited to help you make the transition to Planet 2. (I am currently in the process of converting my packages.) Please do not hesitate to let me know how I can help. This represents the third iteration of the design of Planet 2. (The first was worked on from August 10, 2010 to March 11, 2011. The second in July 2011. The third from August 2011 until now, although coding didn't begin until December 2011.) Enjoy, Jay p.s. In the implementation, I'm particularly proud of the little language for defining command-line interfaces with matching functions (see planet2/main.rkt for a use) and the testing infrastructure that allows you to run sequences of shell commands and check their output (see tests/planet2/tests-install.**rkt for a nice example.) _ Racket Developers list: http://lists.racket-lang.org/**dev http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
The system you are describing is Planet 1. We have it, it isn't necessarily going away. But for many users (such as Carl) it is too expensive to have all these options and we'd like something similar. Planet 2 is based primarily on Linux package systems, like deb/apt, rpm, pacman, etc that lack almost all the features you describe but have been very successful at fostering wide communities. Jay On Thu, Nov 8, 2012 at 3:22 PM, Tobias Hammer tobias.ham...@dlr.de wrote: Just out of curiosity: What are your / the teams objections against some kind of real versioning system that allows to * specify a version number without creating a new package * specify dependencies based on minimal version * keep/pin a package at some particular version (maybe your code depends on an exact, even buggy behavior) * keep directory and file names between incompatible versions without getting banned from solar What made me also wonder when i read the docs is, why is it allowed to have packets that have the same directories as the core racket distribution? Tobias On Thu, 08 Nov 2012 14:16:58 +0100, Jay McCarthy jay.mccar...@gmail.com wrote: Now that the 5.3.1 release is finished, I've just pushed the beta release of Planet 2 to the Racket core. I've tried to answer all questions and explain everything about Planet 2 in the documentation, which I've uploaded a copy of here: http://faculty.cs.byu.edu/~jay/tmp/20121108-pkgs/planet2/index.html In particular, it explains what the plan is to go from this beta release to the final release. If you currently have packages on Planet 1, I am excited to help you make the transition to Planet 2. (I am currently in the process of converting my packages.) Please do not hesitate to let me know how I can help. This represents the third iteration of the design of Planet 2. (The first was worked on from August 10, 2010 to March 11, 2011. The second in July 2011. The third from August 2011 until now, although coding didn't begin until December 2011.) Enjoy, Jay p.s. In the implementation, I'm particularly proud of the little language for defining command-line interfaces with matching functions (see planet2/main.rkt for a use) and the testing infrastructure that allows you to run sequences of shell commands and check their output (see tests/planet2/tests-install.rkt for a nice example.) -- Jay McCarthy j...@cs.byu.edu Assistant Professor / Brigham Young University http://faculty.cs.byu.edu/~jay The glory of God is Intelligence - DC 93 _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
I think it is important that you can get a program from the web, put it into DrRacket, hit run, and get Something Good to happen, without having to go type at command lines and whatnot. (This is especially true for Windows, the platform something like 95% of our users use.) Robby On Thu, Nov 8, 2012 at 3:44 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Thu, Nov 8, 2012 at 3:13 PM, Jay McCarthy jay.mccar...@gmail.com wrote: On Thu, Nov 8, 2012 at 11:01 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: [replying just to a few of these] * I think we should drop the `.plt` archive format entirely. It is the default because Racket can create it and unarchive it natively. If someone implements a native Racket zipper/unzipper, that would be great. My understanding is that this is on Eli's todo list and when it is done, it would be great to change Planet 2's default. Hopefully this can happen before Planet 2's release, so it wouldn't need to support .plt at all. * It would be nice to have fewer special files. For example, `MANIFEST` could be abolished by just fetching the whole content of the directory. Checksums could be included in the `METADATA` file. The manifest is necessary because there's no reliable way to get a directory list from a Web site. Then I would just suggest dropping the web-directory fetching instead, and just support archives at URLs. * In section 3.1, you should have 'git push -u origin master'. This is directly from the Github docs: https://help.github.com/articles/create-a-repo If you create a fresh repo on GH, you get instructions with the `-u` option -- I'm surprised that they haven't updated the help site. * I thought the conclusion of a recent discussion on dev@ was that tests, typed, etc sub-collections *are* preferred. I think I missed this conversation. I don't understand the conclusion given that we don't want to always distribute tests, for example. This discussion was here: http://lists.racket-lang.org/dev/archive/2012-October/010507.html I'm not sure there was a definitive conclusion, but Robby/Eli/Matthias seems to be on the sub-collection side. * Can the Planet1 compatibility also have a version-less translation for the latest version, so that `jaymccarthy/opencl/module` could keep working? I don't want that version-less one to conflict with any of the other ones so that Planet 1 packages that rely on multiple versions will work. Am I missing a part of the request? I'm just suggesting that `../opencl` and `.../opencl1` should both exist. * I think the auto-installing module resolver mentioned in Short Term is a bad idea -- it's already really easy to install packages with this system, and auto-installation just introduces possibility for headaches. I don't think it is *bad* idea, but I also don't think it is *necessary*. But there are other people in the Racket group who think this is totally necessary for Planet 2. I'll let them explain why. I'll look forward to that explanation. -- sam th sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
Perhaps we want a GUI Planet2 installation tool? And options for auto-install from DrRacket to be silent, confirm/cancel, or auto-fail? That would give us the range from full manual control to automatic Something Good happens, all without command lines. Carl Eastlund On Thu, Nov 8, 2012 at 7:44 PM, Robby Findler ro...@eecs.northwestern.eduwrote: I think it is important that you can get a program from the web, put it into DrRacket, hit run, and get Something Good to happen, without having to go type at command lines and whatnot. (This is especially true for Windows, the platform something like 95% of our users use.) Robby On Thu, Nov 8, 2012 at 3:44 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Thu, Nov 8, 2012 at 3:13 PM, Jay McCarthy jay.mccar...@gmail.com wrote: On Thu, Nov 8, 2012 at 11:01 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: [replying just to a few of these] * I think we should drop the `.plt` archive format entirely. It is the default because Racket can create it and unarchive it natively. If someone implements a native Racket zipper/unzipper, that would be great. My understanding is that this is on Eli's todo list and when it is done, it would be great to change Planet 2's default. Hopefully this can happen before Planet 2's release, so it wouldn't need to support .plt at all. * It would be nice to have fewer special files. For example, `MANIFEST` could be abolished by just fetching the whole content of the directory. Checksums could be included in the `METADATA` file. The manifest is necessary because there's no reliable way to get a directory list from a Web site. Then I would just suggest dropping the web-directory fetching instead, and just support archives at URLs. * In section 3.1, you should have 'git push -u origin master'. This is directly from the Github docs: https://help.github.com/articles/create-a-repo If you create a fresh repo on GH, you get instructions with the `-u` option -- I'm surprised that they haven't updated the help site. * I thought the conclusion of a recent discussion on dev@ was that tests, typed, etc sub-collections *are* preferred. I think I missed this conversation. I don't understand the conclusion given that we don't want to always distribute tests, for example. This discussion was here: http://lists.racket-lang.org/dev/archive/2012-October/010507.html I'm not sure there was a definitive conclusion, but Robby/Eli/Matthias seems to be on the sub-collection side. * Can the Planet1 compatibility also have a version-less translation for the latest version, so that `jaymccarthy/opencl/module` could keep working? I don't want that version-less one to conflict with any of the other ones so that Planet 1 packages that rely on multiple versions will work. Am I missing a part of the request? I'm just suggesting that `../opencl` and `.../opencl1` should both exist. * I think the auto-installing module resolver mentioned in Short Term is a bad idea -- it's already really easy to install packages with this system, and auto-installation just introduces possibility for headaches. I don't think it is *bad* idea, but I also don't think it is *necessary*. But there are other people in the Racket group who think this is totally necessary for Planet 2. I'll let them explain why. I'll look forward to that explanation. -- sam th sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
That sounds great. I imagine we'd run online check syntax in auto fail but put a button into the GUI mode. That seems like an easy decision. Maybe the default for Run would be confirm/cancel dialog box with a don't ask again button or something. (I imagine it would actually be auto-fail but where DrRacket notices and offers to install with the usual don't ask me again check box.) Robby On Thu, Nov 8, 2012 at 6:57 PM, Carl Eastlund c...@ccs.neu.edu wrote: Perhaps we want a GUI Planet2 installation tool? And options for auto-install from DrRacket to be silent, confirm/cancel, or auto-fail? That would give us the range from full manual control to automatic Something Good happens, all without command lines. Carl Eastlund On Thu, Nov 8, 2012 at 7:44 PM, Robby Findler ro...@eecs.northwestern.edu wrote: I think it is important that you can get a program from the web, put it into DrRacket, hit run, and get Something Good to happen, without having to go type at command lines and whatnot. (This is especially true for Windows, the platform something like 95% of our users use.) Robby On Thu, Nov 8, 2012 at 3:44 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Thu, Nov 8, 2012 at 3:13 PM, Jay McCarthy jay.mccar...@gmail.com wrote: On Thu, Nov 8, 2012 at 11:01 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: [replying just to a few of these] * I think we should drop the `.plt` archive format entirely. It is the default because Racket can create it and unarchive it natively. If someone implements a native Racket zipper/unzipper, that would be great. My understanding is that this is on Eli's todo list and when it is done, it would be great to change Planet 2's default. Hopefully this can happen before Planet 2's release, so it wouldn't need to support .plt at all. * It would be nice to have fewer special files. For example, `MANIFEST` could be abolished by just fetching the whole content of the directory. Checksums could be included in the `METADATA` file. The manifest is necessary because there's no reliable way to get a directory list from a Web site. Then I would just suggest dropping the web-directory fetching instead, and just support archives at URLs. * In section 3.1, you should have 'git push -u origin master'. This is directly from the Github docs: https://help.github.com/articles/create-a-repo If you create a fresh repo on GH, you get instructions with the `-u` option -- I'm surprised that they haven't updated the help site. * I thought the conclusion of a recent discussion on dev@ was that tests, typed, etc sub-collections *are* preferred. I think I missed this conversation. I don't understand the conclusion given that we don't want to always distribute tests, for example. This discussion was here: http://lists.racket-lang.org/dev/archive/2012-October/010507.html I'm not sure there was a definitive conclusion, but Robby/Eli/Matthias seems to be on the sub-collection side. * Can the Planet1 compatibility also have a version-less translation for the latest version, so that `jaymccarthy/opencl/module` could keep working? I don't want that version-less one to conflict with any of the other ones so that Planet 1 packages that rely on multiple versions will work. Am I missing a part of the request? I'm just suggesting that `../opencl` and `.../opencl1` should both exist. * I think the auto-installing module resolver mentioned in Short Term is a bad idea -- it's already really easy to install packages with this system, and auto-installation just introduces possibility for headaches. I don't think it is *bad* idea, but I also don't think it is *necessary*. But there are other people in the Racket group who think this is totally necessary for Planet 2. I'll let them explain why. I'll look forward to that explanation. -- sam th sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
This is on the long term list in the docs. Jay Sent from my iPhone On 2012/11/08, at 17:59, Carl Eastlund c...@ccs.neu.edu wrote: Perhaps we want a GUI Planet2 installation tool? And options for auto-install from DrRacket to be silent, confirm/cancel, or auto-fail? That would give us the range from full manual control to automatic Something Good happens, all without command lines. Carl Eastlund On Thu, Nov 8, 2012 at 7:44 PM, Robby Findler ro...@eecs.northwestern.eduwrote: I think it is important that you can get a program from the web, put it into DrRacket, hit run, and get Something Good to happen, without having to go type at command lines and whatnot. (This is especially true for Windows, the platform something like 95% of our users use.) Robby On Thu, Nov 8, 2012 at 3:44 PM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Thu, Nov 8, 2012 at 3:13 PM, Jay McCarthy jay.mccar...@gmail.com wrote: On Thu, Nov 8, 2012 at 11:01 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: [replying just to a few of these] * I think we should drop the `.plt` archive format entirely. It is the default because Racket can create it and unarchive it natively. If someone implements a native Racket zipper/unzipper, that would be great. My understanding is that this is on Eli's todo list and when it is done, it would be great to change Planet 2's default. Hopefully this can happen before Planet 2's release, so it wouldn't need to support .plt at all. * It would be nice to have fewer special files. For example, `MANIFEST` could be abolished by just fetching the whole content of the directory. Checksums could be included in the `METADATA` file. The manifest is necessary because there's no reliable way to get a directory list from a Web site. Then I would just suggest dropping the web-directory fetching instead, and just support archives at URLs. * In section 3.1, you should have 'git push -u origin master'. This is directly from the Github docs: https://help.github.com/articles/create-a-repo If you create a fresh repo on GH, you get instructions with the `-u` option -- I'm surprised that they haven't updated the help site. * I thought the conclusion of a recent discussion on dev@ was that tests, typed, etc sub-collections *are* preferred. I think I missed this conversation. I don't understand the conclusion given that we don't want to always distribute tests, for example. This discussion was here: http://lists.racket-lang.org/dev/archive/2012-October/010507.html I'm not sure there was a definitive conclusion, but Robby/Eli/Matthias seems to be on the sub-collection side. * Can the Planet1 compatibility also have a version-less translation for the latest version, so that `jaymccarthy/opencl/module` could keep working? I don't want that version-less one to conflict with any of the other ones so that Planet 1 packages that rely on multiple versions will work. Am I missing a part of the request? I'm just suggesting that `../opencl` and `.../opencl1` should both exist. * I think the auto-installing module resolver mentioned in Short Term is a bad idea -- it's already really easy to install packages with this system, and auto-installation just introduces possibility for headaches. I don't think it is *bad* idea, but I also don't think it is *necessary*. But there are other people in the Racket group who think this is totally necessary for Planet 2. I'll let them explain why. I'll look forward to that explanation. -- sam th sa...@ccs.neu.edu _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Planet 2 Beta Release
On Nov 8, 2012, at 3:13 PM, Jay McCarthy wrote: * I think the places you use 'PLT' in the documentation should be replace with 'Racket maintainers' -- PLT is a research group with lots of overlap with the Racket maintainers. Sure. I disagree with Sam. Racket is owned by PLT Design, Inc. And current and former maintainers are shareholders. PLT is a perfectly fine name. smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
