Hi all, my research group is going to teach using How to Design Programs (2nd ed.), and I'm currently automating deployment of the handin-client with auto-update. Since the handin-client (and the auto-updater) was written for the old "package management system" (Planet), I'm having some trouble — the procedure seem hackier than desirable, in part because I've not mastered Racket package management yet, in part because it's less error-tolerant than I wish. (I'll admit, things will be probably fine for students, just not for me).
I believe a couple of things could be bugs (especially n. 3), but I'll just tell my story and let you judge. (In the end, it finally seems to be working). Meanwhile, if there's enough interest, I could put some effort into sharing the setup (beyond https://github.com/plt/handin/issues/19). 1. IIUC, since the autoupdater works with PLT files, students will have to paste the plugin URL (http://ps.informatik.uni-tuebingen.de/teaching/ws15/info1/handinplugin/utue-info1-ws15.plt) into "Install .plt file". IIUC, that's equivalent to `racket setup -A`, but the latter doesn't seem to accept URLs. Do I really have to download the files beforehand to install them from the command line? Moreover, I haven't found a clean way to uninstall those packages from `(find-user-collects-dir)`. Finally, we've discovered that if the files are renamed the wrong way after downloading (say, to `utue-info1-ws15 (2).plt`), installation goes wrong — which seems very fragile. For students, we're giving instructions to paste the URL to work this around. 2. I discovered that `raco pkg install` seemed to accept URLs to PLT files, if I produce sha1 checksums (but SHA1 is deprecated?!?). That seemed wonderful, but lead to unacceptable problems. So I could just type: $ raco pkg install $(for i in '' -local -staging; do echo http://ps.informatik.uni-tuebingen.de/teaching/ws15/info1/handinplugin/utue-info1-ws15$i.plt; done) and later remove everything with `raco pkg`. However, files end up in `(find-user-pkgs-dir)`, and that's very bad, because `raco setup -A` can install the same package also in `(find-user-collects-dir)` — in particular, that's what happens as soon as you do an auto-update (`raco pkg` refuses instead to do that, after `raco setup` was run). Afterwards, DrRacket seems to try loading the plugin twice, resulting in: ``` Error invoking tool #<path:/Users/pgiarrusso/Library/Racket/6.2.1/pkgs/utue-info1-ws15/utue-info1-ws15>;"client-gui.rkt" preferences:set-default: preferences default already set for 'handin:utue-info1-ws15:submit:username context...: /Users/pgiarrusso/Library/Racket/6.2.1/pkgs/utue-info1-ws15/utue-info1-ws15/client-gui.rkt: [running body] /Applications/Racket v6.2.1/share/pkgs/drracket/drracket/private/tools.rkt:283:4 loop /Applications/Racket v6.2.1/share/pkgs/drracket/drracket/private/tools.rkt:71:0: load/invoke-all-tools /Applications/Racket v6.2.1/share/pkgs/drracket/drracket/tool-lib.rkt: [running body] /Applications/Racket v6.2.1/share/pkgs/drracket/drracket/private/drracket-normal.rkt: [running body] /Applications/Racket v6.2.1/share/pkgs/drracket/drracket/drracket.rkt: [running body] ``` 3. Earlier I was trying to automate `raco pack --collect --at-plt ++setup` using setup/pack, testing the result using `raco planet structure` and getting contract violations. Then I got the same contract violations using `raco planet structure` on a valid .plt file. Finally, I verified that `raco planet structure` understands the result of `raco planet create`, but not necessarily the result of `raco pack`. People on IRC suggested mentioning this here. What do you think? Cheers, Paolo -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
