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.
