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

I'll take it! Thanks for your prescience.


On Aug 29, 2014, at 11:08 AM, Matthew Flatt <mflatt at cs.utah.edu> wrote:

> 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