Re: Summary and next steps for (package-initialize)

[Radon Rosborough <radon.neon@gmail.com>]

> I think you forget that file-local variables support 'eval' forms.

This is different, since such `eval' forms can be processed just by
evaluating them. Whereas the implementation you proposed involved
determining the evaluation result of Lisp code without actually
evaluating it.

> I proposed _an_idea_. You forced me to go into details in an area
> where my expertise leaves a lot to be desired, to say the least.

I see now that your proposal was more general than I took it to be.
I'll try to refrain from overgeneralizing from now on. (I still may
point out flaws in particular implementation ideas, though.)

> Perhaps we should support a separate .package-exclude file under
> ~/.emacs.d, where users would list packages they don't want to load.

This is roughly equivalent to having a second init-file, which is
indeed a valid solution (although it has the disadvantage that users
will inevitably put package.el customizations in their init-files and
then get confused when they don't work).

> Or maybe it'd be good enough to unload the packages not in the list,
> after processing the user init file.

I think the resulting performance regressions make this impractical.
Not to mention that packages can, in general, run arbitrary Lisp code
in their autoloads which cannot be unloaded.

> Or maybe people who set package-load-list should also be told to place
> the call to package-initialize in their init files, but do it
> manually, not automatically by Emacs.

This wouldn't solve the problem of package customizations in the
init-file not working, which is the primary issue. (But just to be
clear, I'm not insisting that you be the one to provide a solution to
that problem just because you made the suggestion.)

> There could be any number of possible solutions for this issue,
> which IMO is minor compared to the larger issue of leaving the user
> init file alone, letting the users manage its content as they see
> fit.

Do you consider a one-time default init-file as violating the
principle of "leaving the user init file alone"? That's a perfectly
reasonable position; I just haven't heard you say that yet.

> And yet we do something similar in file-local variables and
> elsewhere, like the .dir-locals.el files.

I've already said that this is completely different, since file-local
variables can be evaluated directly, whereas anything in the init-file
depends on the runtime behavior of the entire rest of the init-file.

> So there are solutions along these lines that don't violate the
> basic principles, but still solve practical problems in a way that
> is acceptable by the user community.

Is "not allowing dynamic customization of package-load-list"
acceptable by the user community? Honest question. It wouldn't be
acceptable by me but then I don't use package.el.

> Only because you are trying to solve a larger problem than we need to
> solve, and because you are reasoning in absolute terms, rather than in
> practical engineering terms.

I'm just trying to point out that any ahead-of-time static analysis of
the init-file will necessarily fail in some circumstances. If we're OK
with that, then fine, but we have to be aware of it.

> > I started this thread by proposing a specific, comprehensive solution
> > to the problem. Nobody has pointed out any flaws yet. Why is there an
> > impasse?
>
> Because AFAICT no one likes your proposal.

Well, nobody (including you) has told me *why* they don't like my
proposal. If somebody would explain that, then I would stop bringing
it up.

Also, Mark Oteiza clearly likes my proposal, so I think "no one" is an
exaggeration:

    > Radon Rosborough <radon.neon@gmail.com> writes:
    > > Last week I posted an inquiry [1] about package.el's auto-insertion of
    > > code into the init-file. Six people weighed in, but no definitive
    > > conclusion was reached. I would like to propose concrete next steps,
    > > summarizing relevant parts of the discussion in the process.
    >
    > Thanks for pushing the issue.
    >
    > > ==> The proposal
    > >
    > > The `package--ensure-init-file' logic will be removed
    >
    > +1 for reverting.
    >
    > I will happily propose and write documentation for various use cases of
    > package.el, but I will not waste my time as long as the current solution
    > is in place.

In fact, I think Mark is the only person in this whole thread who has
made a specific comment directly on my proposal. (I still haven't
received replies from you or Stefan requesting a specific explanation
of your comments that my proposal is "a non-starter" or will not be
"significantly better".)

In the meantime, here is my analysis of the options we have:

* Require package.el customization to happen in file-local variables.
* Scan the init-file for customization of package.el, and accept that
  this will fail in many cases.
* Introduce a second init-file just for package.el.
* Don't allow package.el to be customized.
* Use a default init-file.
* Require users to understand that the package manager must be loaded
  before packages can be customized.
* Leave it as is, where Emacs modifies the init-file programmatically,
  and accept that this usually does the wrong thing.

Let me know if I missed anything.