Ihor Radchenko <[email protected]> writes:
> Morgan Smith <[email protected]> writes:
>
>> See attached a new patch series
>
> Thanks!
>
>> Things that are different:
>>
>> When installing packages I still override `package-user-dir' to install them
>> into "$(pkgdir)" but when doing other things, I simply add the directory to
>> `package-directory-list' so that users can still use `package-user-dir' if
>> they
>> so choose. However, this could have bad consequences for people using
>> multiple
>> emacs versions that only overwrite `EMACSLOADPATH` and not
>> `package-user-dir'.
>> I'm not familiar with how most people do multiple Emacs versions so please
>> let
>> me know if this is a concern.
>
> Hmm. I tried make repro, and now I get all the autoloads from all the
> packages in my elpa directory with make repro. That's not supposed to
> happen. We need to isolate the environment.
See next paragraph
>> # start Emacs with no user and site configuration
>> # EMACSQ = -vanilla # XEmacs
>> -EMACSQ = $(EMACS) -Q
>> +EMACSQ = $(EMACS) -Q \
>> + --eval '(setq vc-handled-backends nil org-startup-folded nil
>> org-element-cache-persistent nil)' \
>> + --eval '(make-directory "$(pkgdir)" t)' \
>> + --eval '(add-to-list `package-directory-list "$(pkgdir)")' \
>> + -f package-initialize
>
> This will enable all the installed packages where the rest of Makefile
> expects emacs -Q. Basically, you made EMACSQ and equivalent of normal
> emacs command.
My apologies for not catching this problem myself. I'm starting to
realize I might not be the right person for this job as I use the funny
operating system that already overrides and controls all the variables
and directories that we are now trying to override for people on other
operating systems. I'm still more then willing to work on this, it's
just I will be making more oversights like this one.
It looks like there isn't a good way to make use of
`package-directory-list' unless you want to try something really funky
like what is done in `testing/org-batch-test-init.el'.
I guess I'll revert the package-directory-list changes
>> I added a simple override flag to skip cleanpkg when doing the repro target
>
> I tried
> make uppkg EMACS=emacs-29
> make cleanpkg EMACS=emacs-29
> I get
> make: Nothing to be done for 'cleanpkg'.
Not sure how I missed this. I need to be using shell "if", not make
"if". Something like this:
#+begin_src makefile
cleanpkg:
-@if [ -z "$(SKIP_CLEANPKG)" ]; then \
$(RMR) $(pkgdir_top); \
else \
echo "Skipping cleanpkg"; \
fi
#+end_src
>>> Daniel also suggested another approach - ship compat together with Org
>>> mode, just as Emacs ships third-party libraries. Not for ELPA, just for
>>> git repository.
>>>
>>> The idea is to keep your code, but *commit* the compat to Git repo.
>>> Then, we can have a special make target to update compat in git.
>>> WDYT?
>>
>> I've spent a lot of time unvendoring code for the Guix project so asking me
>> to
>> vendor code feels very wrong. I don't really have a good argument against
>> doing it other then that one though.
>
> Could you explain more about unvendoring? What exactly is problematic there?
>
In this specific circumstance it might not be as problematic as it is in
other situations.
The basic reasons are compatibility and security. Should a distro
choose to patch their version of compat.el for compatibility or
security, they won't know to do so on our vendored code. Then it is
possible that problematic byte-code (or even a problematic compat.el)
could be installed by that distro's packaging system.
[[info:guix#Extracting Bundled Dependencies]]
#+begin_example
In Guix every package is supposed to be fully built from source (*note
Bootstrapping::). This is at the heart of the security and user freedom
guarantees provided by the distribution, and it is what allows Guix to
correctly reason about the package graph, to apply transversal changes
(say, a security update on a single library) and have them propagate to
every dependent package.
...
Bundling dependencies conflicts with several Guix invariants:
• When a change must be made in a library—e.g., applying a security
fix or removing pre-generated code—that change would need to be
repeated in every single package that bundles it.
• Guix mainline ships only free software: bundled trees frequently
contain minified blobs whose preferred form for modification is
missing (*note Software Freedom::).
• Duplicated source code inflates the closure size and makes ‘guix
size’ (*note Invoking guix size::) and ‘guix graph’ (*note Invoking
guix graph::) less useful as auditing tools.
#+end_example
>> Are git submodules any good these days? Last I tried they where terrible but
>> also getting regular improvements (this was like 4 years ago).
>
> Still annoying.
>
That sucks. In theory this is the best way to handle this situation.
Anyone who cares about vendored code knows to check the submodules.
However, I would rather vendor code then degrade the developer
experience.
>> +(require 'package)
>> +(require 'lisp-mnt)
>> +
>> +(cl-macrolet
>> + ((static-when (condition &rest body)
>> + (when (eval condition lexical-binding)
>> + (cons 'progn body))))
>> + (static-when (version< emacs-version "29.9999")
>
> Why not just (unless (fboundp ...))?
Oh. Ya that works. Not sure why I did it that way. I'll switch it to
fbound.
* Moving forward
Current situation of the patch series:
- if developer is on a recent Emacs then no change experienced
- if developer needs compat (older emacs) it can be installed in
"pkg-deps/$(VERSION)". It will be wiped away whenever they run "make
cleanall" or "git clean -xfd" so they better have a good internet
connection and hope elpa doesn't go offline if they want to do that
often.
- if developer wants to bring their own compat, they can go to hell
Possible ways forward:
- vendor compat directly in repo
- pros: very simple and robust. Offline friendly
- cons: Morgan will shed a single tear dramatically
- vendor compat using submodules
- pros: Offline friendly
- cons: Endless frustration
- accept current solution
- pros: No vendoring. Easy to add more packages in future
- cons: Online dependent.
- figure out a better way for users to bring their own compat
- pros: No vendoring. Easy to add more packages in future
- cons: Developer has to manually configure a thing or deal with
online dependence
Please let me know what you think!
