Re: [racket-dev] make --clone installed pkgs
At Tue, 17 Feb 2015 19:59:38 -0500, Sam Tobin-Hochstadt wrote: On Tue, Feb 17, 2015 at 6:41 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Tue, 17 Feb 2015 14:12:54 -0500, Sam Tobin-Hochstadt wrote: Does another system have a Racket-like in-place option (that works better)? I haven't used it, but GHC has an in-place build option where you can install packages; see [1]. I don't have a lot of experience with GHC, but I have talked to some GHC and Cabal developers about how they work with the package system. Those discussions did not lead me to believe that they have an especially smooth system for working with packages and updates in-place --- and, in particular, that it's not the way they normally work. I'd be happy to hear more from someone who routinely works that way with GHC, though. I think the closer analogy is to what other software does when you run both `make` and `make install` analagous to Racket's unix-style installation, since that's the recommended way of building (eg Python), just as in-place is the recommended way of building Racket from source. I don't think any of those systems update packages when running `make install`. I'm not sure what you're getting at here. We seem to agree that the usual `make` plus `make install` is like Racket's `make unix-style`, neither of which updates packages (other than the ones the makefile knows about). At Tue, 17 Feb 2015 17:40:36 -0500, Matthias Felleisen wrote: Speaking as the user I am, I really like it that make updates my extra-pkgs. Package scope provides one a way to get these different behaviors. The current `make` updates only packages that are in installation scope, and it also sets installation scope to be the default, so that's why `make` tends to update everything that is installed. Maybe Sam should install additional packages in user scope, and then `make` won't try to update them. I expect that the packages that update for Matthias on `make` are packages in main-distribution Ah, no. I've helped Matthias when problems break his installation, I've noticed that he installs packages not in main-distribution (e.g., marketplace), and I believe he really does want those updated. I had that context in mind but didn't think to spell it out as I should have. As an aside, the reason I don't install in user scope is that I switch between Racket implementations regularly, which would lead to out-of-date zo errors for all my user packages (instead, I get multiple copies of the packages). You can give each installation a different name (using `raco pkg config --set name ...`) to avoid the collision. That would be an extra step in setting up each new installation, though. I don't have a strong opinion on whether `make` should update packages outside of main-distribution, but the feedback I'm getting is * Sam doesn't think they should be updated --- but he also doesn't want packages in main-distribution updated, so he's going to use `make as-is`. * Everyone else who has spoken up seems to prefer an updating `make`, so far. -- You received this message because you are subscribed to the Google Groups Racket Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+unsubscr...@googlegroups.com. To post to this group, send email to racket-...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/20150218125203.667906501B8%40mail-svr1.cs.utah.edu. For more options, visit https://groups.google.com/d/optout.
Re: [racket-dev] make --clone installed pkgs
That seems like a fair summary and since my preference is clearly the minority one, I'm happy to stick with 'make as-is'. The new mode for pulling updates will help, as well. Sam On Wed, Feb 18, 2015, 7:52 AM Matthew Flatt mfl...@cs.utah.edu wrote: At Tue, 17 Feb 2015 19:59:38 -0500, Sam Tobin-Hochstadt wrote: On Tue, Feb 17, 2015 at 6:41 PM, Matthew Flatt mfl...@cs.utah.edu wrote: At Tue, 17 Feb 2015 14:12:54 -0500, Sam Tobin-Hochstadt wrote: Does another system have a Racket-like in-place option (that works better)? I haven't used it, but GHC has an in-place build option where you can install packages; see [1]. I don't have a lot of experience with GHC, but I have talked to some GHC and Cabal developers about how they work with the package system. Those discussions did not lead me to believe that they have an especially smooth system for working with packages and updates in-place --- and, in particular, that it's not the way they normally work. I'd be happy to hear more from someone who routinely works that way with GHC, though. I think the closer analogy is to what other software does when you run both `make` and `make install` analagous to Racket's unix-style installation, since that's the recommended way of building (eg Python), just as in-place is the recommended way of building Racket from source. I don't think any of those systems update packages when running `make install`. I'm not sure what you're getting at here. We seem to agree that the usual `make` plus `make install` is like Racket's `make unix-style`, neither of which updates packages (other than the ones the makefile knows about). At Tue, 17 Feb 2015 17:40:36 -0500, Matthias Felleisen wrote: Speaking as the user I am, I really like it that make updates my extra-pkgs. Package scope provides one a way to get these different behaviors. The current `make` updates only packages that are in installation scope, and it also sets installation scope to be the default, so that's why `make` tends to update everything that is installed. Maybe Sam should install additional packages in user scope, and then `make` won't try to update them. I expect that the packages that update for Matthias on `make` are packages in main-distribution Ah, no. I've helped Matthias when problems break his installation, I've noticed that he installs packages not in main-distribution (e.g., marketplace), and I believe he really does want those updated. I had that context in mind but didn't think to spell it out as I should have. As an aside, the reason I don't install in user scope is that I switch between Racket implementations regularly, which would lead to out-of-date zo errors for all my user packages (instead, I get multiple copies of the packages). You can give each installation a different name (using `raco pkg config --set name ...`) to avoid the collision. That would be an extra step in setting up each new installation, though. I don't have a strong opinion on whether `make` should update packages outside of main-distribution, but the feedback I'm getting is * Sam doesn't think they should be updated --- but he also doesn't want packages in main-distribution updated, so he's going to use `make as-is`. * Everyone else who has spoken up seems to prefer an updating `make`, so far. -- You received this message because you are subscribed to the Google Groups Racket Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+unsubscr...@googlegroups.com. To post to this group, send email to racket-...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/CAK%3DHD%2BbRiPnX%3DuWH2x6UjQTzkEZn5nR-UNb-9Bka8wvZHBx-GA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-dev] make --clone installed pkgs
On Tue, Feb 17, 2015 at 8:49 PM, Matthias Felleisen matth...@ccs.neu.edu wrote: On Feb 17, 2015, at 7:59 PM, Sam Tobin-Hochstadt wrote: I expect that the packages that update for Matthias on `make` are packages in main-distribution, Personally, I have used the 'same' one-line command going back to csv through svn and now git (_update). When I write Speaking as the user I am .. I am thinking of people like me. Then again, you're probably saying that I am the bottom element of the lattice of make/update knowledge, so never mind what I write. No, what I mean is that many (all?) of the packages you're thinking of are ones, like 2htdp, that are part of main-distribution, and thus you're in a different position than someone who develops packages that are not part of the distribution. I certainly don't think you're the bottom element in that lattice -- after all, you've written a shell script to automate your work. Sam -- You received this message because you are subscribed to the Google Groups Racket Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+unsubscr...@googlegroups.com. To post to this group, send email to racket-...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/CAK%3DHD%2BYwVcHtYc%2BKCOMU4bCsLCyzaFwyB-9E8uPzBV8%2BsJvqdg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[racket-dev] make --clone installed pkgs
Sam and I have run into a situation where `make` fails because we've set up clone pkgs and made local modifications in a way that makes the git commands fail [*]. My guess is that the right thing to do is for me to know about these pkgs and do something special when running make. I'm thinking that I could let make finish the initial steps until it gets to the step where it updates the pkgs and then do the update step myself and then run `make as-is`. But the problem with this is that I don't see what command I can run that will update all of the pkgs except the problematic ones. Like I could imagine a `raco pkg update --all-except-clones` or something, but that feels a bit strange as there could be other development modes that would also run into similar problems. Maybe `raco pkg update --all-things-from-this-catalog the-catalog-I-currently-get-main-distribution-from` or something along those lines is the way to go? In general, it seems right for me to run some commands whose complications are roughly proportional to the number of pkgs that I have installed as clones (and where I'm actively developing them) but not to run some commands that require me to do something special for each pkg that is installed. Any ideas? Or am I just missing the right command? Thanks, Robby [*] In my case, in case this suggests a better/different approach to a resolution: the `raco pkg update` step eventually gets to this git command: git merge --ff-only sha1 where the sha1 is the checksum from the pkg server, I believe. In my case, this is a different branch than is currently checked in my clone'd pkg and so the git merge command fails (and that command failing seems like the right behavior for the setup I'd like to be able to use). -- You received this message because you are subscribed to the Google Groups Racket Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+unsubscr...@googlegroups.com. To post to this group, send email to racket-...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/CAL3TdONOjL3_y8U_A1ZUoz_1Z%3DE3HjVV8by9e%2B2dS-W2mc51pg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [racket-dev] make --clone installed pkgs
I think there are two seperable issues here: 1. Can we make `raco pkg update -a` better/more robust in this case? 2. Should `make` run `raco pkg update -a`? In reverse order: - I think `make`, by default, shouldn't update anything, and that we should have a different Makefile target which updates things when people want that explicitly. The current behavior is especially problematic because it updates things that aren't in main-distribution, meaning that it's making potentially arbitrary breaking changes to software on your computer (not just to core Racket). This could be more inconvenient for someone working widely on core packages, but if they wanted the current behavior it would be just `make update` (or some other name) instead of `make`. As someone who does work on a lot of core packages, I'd prefer greater explicitness. - I think `raco pkg update p` where `p` is a cloned package should only do anything if (a) the currently-checked-out branch is the one in the pkg source and (b) the `git merge --ff-only` command would succeed. Otherwise, I think it should just print a message and leave the repository as it is. I think that's what I wanted all the times that this operation has failed in my experience. Sam On Tue, Feb 17, 2015 at 9:54 AM, Robby Findler ro...@eecs.northwestern.edu wrote: Sam and I have run into a situation where `make` fails because we've set up clone pkgs and made local modifications in a way that makes the git commands fail [*]. My guess is that the right thing to do is for me to know about these pkgs and do something special when running make. I'm thinking that I could let make finish the initial steps until it gets to the step where it updates the pkgs and then do the update step myself and then run `make as-is`. But the problem with this is that I don't see what command I can run that will update all of the pkgs except the problematic ones. Like I could imagine a `raco pkg update --all-except-clones` or something, but that feels a bit strange as there could be other development modes that would also run into similar problems. Maybe `raco pkg update --all-things-from-this-catalog the-catalog-I-currently-get-main-distribution-from` or something along those lines is the way to go? In general, it seems right for me to run some commands whose complications are roughly proportional to the number of pkgs that I have installed as clones (and where I'm actively developing them) but not to run some commands that require me to do something special for each pkg that is installed. Any ideas? Or am I just missing the right command? Thanks, Robby [*] In my case, in case this suggests a better/different approach to a resolution: the `raco pkg update` step eventually gets to this git command: git merge --ff-only sha1 where the sha1 is the checksum from the pkg server, I believe. In my case, this is a different branch than is currently checked in my clone'd pkg and so the git merge command fails (and that command failing seems like the right behavior for the setup I'd like to be able to use). -- You received this message because you are subscribed to the Google Groups Racket Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+unsubscr...@googlegroups.com. To post to this group, send email to racket-...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/CAL3TdONOjL3_y8U_A1ZUoz_1Z%3DE3HjVV8by9e%2B2dS-W2mc51pg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Racket Developers group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+unsubscr...@googlegroups.com. To post to this group, send email to racket-...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/CAK%3DHD%2BbYrWHAxWssmvXFA%2BA0tco2RDAXwORQj_iwOq%3DpYXzZOA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
