On Tue, Feb 17, 2015 at 1:03 PM, Matthew Flatt <[email protected]> wrote: > 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.)
I continue to think that updating pkgs automatically is the wrong default, but regardless of where we end up on the default I don't know if adding yet more make targets is a good idea. I can switch to using `make as-is`. Regardless of that, though, I think we should switch to updating only "main-distribution" (and perhaps "main-distribution-tests"). I doubt people expect `make` in the Racket source tree to update their software somewhere else on their machine -- I certainly would be very unpleasantly surprised if that happened to me when rebuilding some other language I had installed. > - 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. I think there's an important difference between ignoring failures and not trying to merge in situations where it doesn't make sense. For example, if some other branch is checked out, I don't think skipping updating is "ignoring failure". I guess I would label my preference `--pull conservative` and that even if you miss the warning, it wouldn't be so bad -- you almost certainly didn't want to change the package in that case. Relatedly, perhaps `raco setup` and `raco pkg update` have too much output currently, making it harder to see warnings? Sam > > 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/CAK%3DHD%2BbC3%3DvP7yLpmacOw%2BOrZADcYQDjecvBLSE-BK3Y8qLmCA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
