[racket] Should `raco pkg update <x>` presume --update-deps?

The `update-implies` declaration, which was added just a few weeks ago,
implements the update behavior that you want.

(Your suggestion of `latest` as a version specification is nicer, but
`update-implies` creates fewer compatibility issues and touches less
code.)

We added `update-implies` with packages like "xrepl-test" and
"xrepl-lib" in mind, where "xrepl-test" is so tightly bound to
"xrepl-lib" that it only makes sense to update the former when also
updating the latter. Also, those packages will always be in the same
source repository, even though we want to keep them as separate
packages to allow more precise dependency specifications.

Although "pollen" doesn't seem so tightly bound to "txexpr" and
"sugar", you make a fine case for adding

 (define update-implies '("txexpr" "sugar"))

to the "info.rkt" of "pollen".

At Fri, 29 Aug 2014 10:21:54 -0700, Matthew Butterick wrote:
> Exhuming this thread because I've recently encountered this issue too —
> expecting `raco pkg update ...` to update dependencies, and then it
> doesn't.
> 
> Reviewing the correspondence we have:
> 
> 1. The Hendershott option — automatic dependency updating by default
> 2. The McCarthy option — dependency updating only when asked
> 
> I understand the logic of both. Yet we could add more options to the pile:
> 
> 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 ...`)
> 
> 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.)
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> For instance, here's the current Pollen dependency line:
> 
> (define deps '(("base" #:version "6.0") "txexpr" "sugar" ("markdown"
> #:version "0.18") "htdp"))
> 
> 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.
> 
> Whereas if I could do this:
> 
> (define deps '(("base" #:version "6.0") ("txexpr" #:version 'latest)
> ("sugar" #:version 'latest) ("markdown" #:version "0.18") "htdp"))
> 
> 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.
> 
> 
> 
> 
> 
> On Mon, Nov 11, 2013 at 8:18 AM, Greg Hendershott <greghendershott at gmail.com
> > wrote:
> 
> > I agree this example isn't a good reason to make --update-deps the default.
> >
> > I expected `raco pkg update x` would update x and all its
> > dependencies. My expectation was wrong. What might be a good reason
> > would be if many other people shared this wrong expectation, but I
> > don't know that's the case.
> >
> > On Mon, Nov 11, 2013 at 10:07 AM, Jay McCarthy <jay.mccarthy at gmail.com>
> > wrote:
> > > On Mon, Nov 11, 2013 at 7:44 AM, Greg Hendershott
> > > <greghendershott at gmail.com> wrote:
> > >> In response to my "I can't think of a situation" you raise with your
> > >> own "I can't think of a situation". Well played sir. :)
> > >>
> > >> The updated markdown parser is more likely to handle some corner cases
> > >> than the old one, e.g. being less finicky about requiring a blank line
> > >> after some element.
> > >>
> > >> I had updated Frog to be able to use the new version and give those
> > >> improved results, but still be compatible with the older version.
> > >>
> > >> I guess my thinking was, the newer parser was such a huge redesign, I
> > >> wanted the safety net of someone being able to revert to the older
> > >> version (at least temporarily).
> > >>
> > >> So that's why I bumped the ver on the markdown, but not the ver for
> > >> frog's dep on it.
> > >>
> > >> Probably I over-thunk it. And the new parser seems solid so far. As a
> > >> result, I should just bump frog's own version, and bump the version of
> > >> markdown it requires. And then all will be well.
> > >>
> > >> As for the general question: I think you're saying that with the
> > >> status quo `raco pkg update <x>`, if an installed dep is older than
> > >> required, it will install the very latest version (perhaps newer than
> > >> required), otherwise it will do nothing?  Whereas with --update-deps
> > >> it does the equivalent of an individual `raco pkg update <dep>` on
> > >> every dep transitively, so you'll end up with the very latest of
> > >> everything?
> > >
> > > Yes, that's correct. As you mention "update = remove + install", I
> > > hope this result is predictable. Imagine, for a moment that someone
> > > used your old markdown package with my unreleased super-secret Racket
> > > Wiki server. Then, they decided that they wanted your blog engine too.
> > > You wouldn't expect installing "frog" to update the markdown package.
> > > Since "raco pkg update <x>" is literally just removing the package and
> > > adding it again (with a tiny bit of a barrier in case the second
> > > install fails), it works the same way.
> > >
> > > I don't have a strong opinion about your suggestion of switching the
> > > default behavior, but I'm not sure your example is the best reason to
> > > switch it.
> > >
> > > My attitude is that when you "raco pkg update <x>" you are planning on
> > > getting new behavior in <x> and not "error fixes on <x> and everything
> > > else that it uses" (where "better Markdown parsing" can be seen as a
> > > fixing an error in the old parser). But when you use "--update-deps"
> > > (or "-a") then you are planning on just looking for new versions of
> > > anything. I like the feeling of stability this pattern gives.
> > >
> > > One case where I think "--update-deps" should definitely be implied is
> > > when a package "implies" other packages, such as 'main-distribution'
> > > implying 'srfi', because the "implies" is transparent, so the user
> > > doesn't necessarily know which package is really providing the feature
> > > they want updated.
> > >
> > > In any case, I think I will probably be able to continuing living if
> > > "--update-deps" were the default, but I want a better example or a few
> > > +1s.
> > >
> > > Jay
> > >
> > > --
> > > Jay McCarthy <jay at cs.byu.edu>
> > > Assistant Professor / Brigham Young University
> > > http://faculty.cs.byu.edu/~jay
> > >
> > > "The glory of God is Intelligence" - D&C 93
> > ____________________
> >   Racket Users list:
> >   http://lists.racket-lang.org/users
> >
> ____________________
>   Racket Users list:
>   http://lists.racket-lang.org/users