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 > <[email protected]> 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 [email protected]. > > To post to this group, send email to [email protected]. > > 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. 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.
