On Tue, Feb 17, 2015 at 1:03 PM, Matthew Flatt <mfl...@cs.utah.edu> 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
>> <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/CAK%3DHD%2BbC3%3DvP7yLpmacOw%2BOrZADcYQDjecvBLSE-BK3Y8qLmCA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to