<div dir="ltr">Exhuming this thread because I've recently encountered this issue too — expecting `raco pkg update ...` to update dependencies, and then it doesn't. <div><br></div><div>Reviewing the correspondence we have:<div>
<br></div><div>1. The Hendershott option — automatic dependency updating by default</div><div>2. The McCarthy option — dependency updating only when asked</div><div><br></div><div>I understand the logic of both. Yet we could add more options to the pile:</div>
<div><br></div><div>3. The user option — `raco pkg update ...` puts up a user prompt if it notices that dependencies have changed (similar to what happens with `raco pkg install ...`)</div><div><br></div><div>4. The Not All Dependencies Are Equal option — this is where I'm at. My Pollen package depends on two other packages that I maintain (Sugar & Txexpr) but also some packages I don't maintain (Markdown & Rackjure et al.) </div>
<div><br></div><div>Some bugs that arise in Pollen are really bugs in Sugar or Txexpr. So in one sense, I would like `raco pkg update ...` to always update those dependencies.</div><div><br></div><div>But Pollen doesn't depend as sensitively on Markdown et al. So, similar to Jay's secret-wiki-server example, I don't want to tell users to do `raco pkg update --update-deps ...` because it might bring in new versions of Markdown et al. that destabilize user installations.</div>
<div><br></div><div>5. The Just Use Versioning option — I gather that I could manage all this manually by adding version requirements to Pollen's 'info.rkt' file. For instance: update the Sugar package, update the Sugar package version, update Pollen's dependency on with the new Sugar version number, and then `raco pkg update pollen` will get the Sugar update but leave others alone.</div>
<div><br></div><div>But I don't like this option, because it a) puts me into the version-tracking business and b) feels it like undermines one of the nice principles of the Racket package system, which is letting us care about checksums rather than versions when that makes sense.</div>
<div><br></div><div>As I say that, I wonder if a solution would be to allow a package maintainer to determine the behavior of `racket pkg update ...` from within 'info.rkt', perhaps by adding a 'latest option to the #:version field.</div>
<div><br></div><div>For instance, here's the current Pollen dependency line:</div><div><br></div><div>(define deps '(("base" #:version "6.0") "txexpr" "sugar" ("markdown" #:version "0.18") "htdp"))<br>
</div><div><br></div><div>Right now `raco pkg update pollen` won't update Markdown unless I bump the #:version. I like that. But it won't update Txexpr or Sugar either. I don't like that.</div><div><br></div><div>
Whereas if I could do this:</div><div><br></div><div><div>(define deps '(("base" #:version "6.0") ("txexpr" #:version 'latest) ("sugar" #:version 'latest) ("markdown" #:version "0.18") "htdp"))<br>
</div></div><div><br></div><div>That could be the signal that `raco pkg update pollen` should always scoop up any available updates for Txexpr and Sugar too, while leaving Markdown alone as usual.</div><div><br></div><div>
<br></div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Nov 11, 2013 at 8:18 AM, 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>