[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Summary and next steps for (package-initialize)
From: |
Radon Rosborough |
Subject: |
Re: Summary and next steps for (package-initialize) |
Date: |
Tue, 22 Aug 2017 11:09:41 -0700 |
> 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 <address@hidden> 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.
- Re: Summary and next steps for (package-initialize), (continued)
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/20
- Re: Summary and next steps for (package-initialize), Eli Zaretskii, 2017/08/21
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/21
- Re: Summary and next steps for (package-initialize), Eli Zaretskii, 2017/08/21
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/21
- Re: Summary and next steps for (package-initialize), Eli Zaretskii, 2017/08/21
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/22
- Re: Summary and next steps for (package-initialize), Clément Pit-Claudel, 2017/08/22
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/22
- Re: Summary and next steps for (package-initialize), Eli Zaretskii, 2017/08/22
- Re: Summary and next steps for (package-initialize),
Radon Rosborough <=
- Re: Summary and next steps for (package-initialize), Clément Pit-Claudel, 2017/08/22
Re: Summary and next steps for (package-initialize), Stefan Monnier, 2017/08/21
- Re: Summary and next steps for (package-initialize), Eli Zaretskii, 2017/08/21
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/21
- Re: Summary and next steps for (package-initialize), Clément Pit-Claudel, 2017/08/21
- Re: Summary and next steps for (package-initialize), Timur Aydin, 2017/08/22
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/22
- Re: Summary and next steps for (package-initialize), Clément Pit-Claudel, 2017/08/22
- Re: Summary and next steps for (package-initialize), Radon Rosborough, 2017/08/23
- Re: Summary and next steps for (package-initialize), Angelo Graziosi, 2017/08/23