Continuing in reverse order: - My sense is that the switch to `make` so that it updates packages, which was a result of
http://lists.racket-lang.org/users/archive/2015-January/065345.html has been a good change for most people most of the time. The `as-is` target is currently available for building without updating packages. I think it would make sense to introduce `make as-is-the-default` to effectively change the default `make` target to be `make as-is`. (And there would be `make with-update` to get the current behavior of `make` after `make as-is-the-default`, plus `make with-update-the-default` for completeness.) - It makes sense to me to add a `--pull` option to `raco pkg update` for specifying the behavior of the `git pull` step for linked clones. I imagine that the default would be `--pull ff-only` for the current behavior, while `--pull try` would ignore fast-forward failures. I think I'd also like `--pull rebase`. I'm skeptical that making `--pull try` the default would be a good idea. People have trouble seeing warnings. Would those changes work? At Tue, 17 Feb 2015 10:38:43 -0500, Sam Tobin-Hochstadt wrote: > 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%3DE3HjV > V8by9e%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%2BA0tco > 2RDAXwORQj_iwOq%3DpYXzZOA%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/20150217180324.56E066501AA%40mail-svr1.cs.utah.edu. For more options, visit https://groups.google.com/d/optout.
