<div dir="ltr"><div><div><div><div><div><div>I don't have a strong opinion yet on which default is better, but consider the following case:<br></div>If user A installs package X that depends on Y, and does not yet have Y, then he will have both new versions of X and Y.<br>
</div>But a user who already has an old version package Y and installs X will have a different installation than the other user, which seems strange and may lead to difficulties in debugging package X failures from user reports.<br>
<br></div>For me, as long as a package Y is updated by either fixing bugs or adding new features while leaving the old features untouched, and is therefore not backward incompatible, should count only as "same version, only better".<br>
</div>However, if a package X is updated but depends on the new features/bug fixes of Y, then it may break.<br><br></div>So I tend to think that all dependencies should be updated along with a package, as long as the dependencies themselves respect the "no-backward-incompatibility" change.<br>
<br></div>Or maybe I misunderstand the package system.<br><br>Laurent<br><div><div><div><div><br><div><br></div></div></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 11, 2013 at 5:18 PM, Greg Hendershott <span dir="ltr"><<a href="mailto:greghendershott@gmail.com" target="_blank">greghendershott@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I agree this example isn't a good reason to make --update-deps the default.<br>
<br>
I expected `raco pkg update x` would update x and all its<br>
dependencies. My expectation was wrong. What might be a good reason<br>
would be if many other people shared this wrong expectation, but I<br>
don't know that's the case.<br>
<div class="HOEnZb"><div class="h5"><br>
On Mon, Nov 11, 2013 at 10:07 AM, Jay McCarthy <<a href="mailto:jay.mccarthy@gmail.com">jay.mccarthy@gmail.com</a>> wrote:<br>
> On Mon, Nov 11, 2013 at 7:44 AM, Greg Hendershott<br>
> <<a href="mailto:greghendershott@gmail.com">greghendershott@gmail.com</a>> wrote:<br>
>> In response to my "I can't think of a situation" you raise with your<br>
>> own "I can't think of a situation". Well played sir. :)<br>
>><br>
>> The updated markdown parser is more likely to handle some corner cases<br>
>> than the old one, e.g. being less finicky about requiring a blank line<br>
>> after some element.<br>
>><br>
>> I had updated Frog to be able to use the new version and give those<br>
>> improved results, but still be compatible with the older version.<br>
>><br>
>> I guess my thinking was, the newer parser was such a huge redesign, I<br>
>> wanted the safety net of someone being able to revert to the older<br>
>> version (at least temporarily).<br>
>><br>
>> So that's why I bumped the ver on the markdown, but not the ver for<br>
>> frog's dep on it.<br>
>><br>
>> Probably I over-thunk it. And the new parser seems solid so far. As a<br>
>> result, I should just bump frog's own version, and bump the version of<br>
>> markdown it requires. And then all will be well.<br>
>><br>
>> As for the general question: I think you're saying that with the<br>
>> status quo `raco pkg update <x>`, if an installed dep is older than<br>
>> required, it will install the very latest version (perhaps newer than<br>
>> required), otherwise it will do nothing? Whereas with --update-deps<br>
>> it does the equivalent of an individual `raco pkg update <dep>` on<br>
>> every dep transitively, so you'll end up with the very latest of<br>
>> everything?<br>
><br>
> Yes, that's correct. As you mention "update = remove + install", I<br>
> hope this result is predictable. Imagine, for a moment that someone<br>
> used your old markdown package with my unreleased super-secret Racket<br>
> Wiki server. Then, they decided that they wanted your blog engine too.<br>
> You wouldn't expect installing "frog" to update the markdown package.<br>
> Since "raco pkg update <x>" is literally just removing the package and<br>
> adding it again (with a tiny bit of a barrier in case the second<br>
> install fails), it works the same way.<br>
><br>
> I don't have a strong opinion about your suggestion of switching the<br>
> default behavior, but I'm not sure your example is the best reason to<br>
> switch it.<br>
><br>
> My attitude is that when you "raco pkg update <x>" you are planning on<br>
> getting new behavior in <x> and not "error fixes on <x> and everything<br>
> else that it uses" (where "better Markdown parsing" can be seen as a<br>
> fixing an error in the old parser). But when you use "--update-deps"<br>
> (or "-a") then you are planning on just looking for new versions of<br>
> anything. I like the feeling of stability this pattern gives.<br>
><br>
> One case where I think "--update-deps" should definitely be implied is<br>
> when a package "implies" other packages, such as 'main-distribution'<br>
> implying 'srfi', because the "implies" is transparent, so the user<br>
> doesn't necessarily know which package is really providing the feature<br>
> they want updated.<br>
><br>
> In any case, I think I will probably be able to continuing living if<br>
> "--update-deps" were the default, but I want a better example or a few<br>
> +1s.<br>
><br>
> Jay<br>
><br>
> --<br>
> Jay McCarthy <<a href="mailto:jay@cs.byu.edu">jay@cs.byu.edu</a>><br>
> Assistant Professor / Brigham Young University<br>
> <a href="http://faculty.cs.byu.edu/~jay" target="_blank">http://faculty.cs.byu.edu/~jay</a><br>
><br>
> "The glory of God is Intelligence" - D&C 93<br>
____________________<br>
Racket Users list:<br>
<a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br>
</div></div></blockquote></div><br></div>