[racket-dev] experience using the `pkg` branch

I'll try to respond to these four messages at the same time...

Sam said,
> In addition to the larger point Robby makes, this can be pretty
> confusing.  For example, you can fail to install enough dependencies,
> I think.
>
> Another problem is that there's no way to know what to do to fix
> things.  Say there's an error in `raco setup` that's transient (the
> machine lost power, for example).  What command do I run to 'fix' the
> setup? I don't even know what collections were being installed.

On Thu, Jun 13, 2013 at 9:27 PM, Robby Findler
<robby at eecs.northwestern.edu> wrote:
> I know it runs it. I don't know why Jay writes "The package system says
> something is installed when the files are in place and the link is made.
> From some perspective, that's its job.". I can't tell if there's some
> technical piece I'm missing or not (on the surface, these words sound almost
> lazy but I *KNOW* Jay is anything but lazy!)
>
> Robby
>
>
> On Thu, Jun 13, 2013 at 10:21 PM, Carl Eastlund <cce at ccs.neu.edu> wrote:
>>
>> It does run 'raco setup', it just doesn't have much to do in response to a
>> failure, at least right now.
>>
>> Carl Eastlund
>>
>> On Thu, Jun 13, 2013 at 11:14 PM, Robby Findler
>> <robby at eecs.northwestern.edu> wrote:
>>>
>>> Also, Jay: can you explain more why 'raco setup' isn't something that we
>>> should think about as running "inside" the pkg manager? (I'm not saying that
>>> automatically rolling back packages is the right thing to do or anything
>>> like that, but I would like to understand the model you have better.)

Short:

I interpret these messages to be saying, "raco pkg printed error
messages and didn't say what was wrong or what I should do about
it". The messages came from 'raco setup', of course, and 'raco pkg'
gave no interpretation.

As a simple first step, we can have 'raco pkg' observe the output of
'raco setup' (which might require changing it) and if it gives any
error message of any kind, end with a message like:

"raco pkg detected strange output during setup. This could mean there
was a problem. If you would like to undo this command, run:

  raco pkg remove the-package-you-installed"

This sounds like a simple to change to make, but there's one big
problem. After 'raco pkg update' runs, the undo command is much more
complicated and scary in its own way

  raco pkg remove --force the-package-you-updated
  raco pkg install the-source-for-the-package-you-updated-at-the-old-git-commit

But some package sources may not be possible to get back, such as an
old tar ball that you downloaded and don't have any more.

When raco pkg update runs normally, it leaves the old files in place
until the end and then deletes them. It could put these into some sort
of 'archive' location to facilitate that. But it's a big change and
easy to get very wrong.

Long:

I also interpret these messages to be saying

"When raco pkg returns with exit status 0, the packages I asked to be
install/updated should 'work'."

This is a reasonable wish, but I don't think it can be enforced
technically. Let's un-ravel worked-ness:

1. Does the task I thought it would do

  Clearly no way to ensure this. No package system does this.

2. Every file executes without errors

  This is what DrDr normally does and is too burdensome for every
  package, and includes problems of the next stage. No package system
  does this.

3. Passes its test cases on my system

  CPAN is fairly unique in doing this upon install, but virtually no
  other package system does this. I don't think it is actually useful,
  because there's no reason to have confidence in the test cases and
  it's hard from a test case writer perspective to get everything in
  place. (For example, a Mongo DB interface needs a running Mongo DB
  server to test against.)

4. Compiles on my system

  Most package systems don't need to think about this, because they
  ship only binaries. Languages like Perl and Javascript also don't
  really do this, because they don't compile in any real
  sense. Languages that do can typically make a pretty simple promise
  based on their languages inability to have bizarre and
  unpredicatable compile-time dependencies.

  Racket has the ability to provide bizarre and unpredictable
  compile-time dependencies:

  #lang racket/base

  (define-syntax (macro-invocation stx)
   (if matthew-isn't-looking
    #'(require #,(random-file))
    #'(void)))
  (macro-invocation)

  Since we can't really offer this, the best we can do is trust the
  dependencies listed. We have ideas on how to enforce those
  dependencies, but it isn't implemented yet.

5. Its actual dependencies are on my system

  This is like the above.

6. Its listed dependencies are on my system

  This is the standard that 'raco pkg' uses. It guarantees that either
  all dependencies are installed or that no changes were made. This
  means that you can never run 'raco pkg update', download a new
  version of an installed package that has a new dependency that
  conflicts with a current package, and then end up with a failure
  that results in some new packages and some old packages.

  This, by the way, is the most common standard of 'worked-ness' on
  Linux package systems, like pacman, apt-get, etc, that 'raco pkg' is
  based on. These end-user tools don't enforce anything when an
  install happens and sometimes there are mistakes by package
  developers that cause something to break on an end-user system and
  it has to be dealt with somewhere on the developer side.

In other words, there is *no* error that can happen during 'raco
setup' that breaks the package system. Sam's question about what do I
run to "fix" things doesn't make sense to me, because there can't be
anything wrong at that point. If you are using links and then go
change the code in response to a 'raco setup' error, you don't need to
tell the package system at all, you just run 'raco setup' (with no
arguments so it runs on everything) again.

--

Given that I think we can't enforce higher standards technically, my
goal has been to enforce standard (2) with the concept of ring-0
packages. To remind you,

 ring-2: No constraints

 ring-1: Cannot conflict with any package in ring-1 or ring-0.

 ring-0: Must contain tests that I can run on DrDr and that pass
 reliably

Once that is in place, the next step would to make it "difficult" to
install anything other than ring-0 packages. (For instance, not
offering auto-install and not having them in the central documentation
site.) The goal would be to make it so that 'raco setup' never errors.



--
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