Morgan Smith <[email protected]> writes:
>> 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.
I do not think that this particular issue has anything to do with your
OS. Just ol'n'good oversight. Not a big deal.
> 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
Yeah.
I think we can introduce something similar to BTEST_POST, so that people
can direct Org to specific lisp directory. Maybe even dedicated variable
like USE_EMACS_D or similar to explicitly make Org include user
user-emacs-directory. WDYT?
>>> 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
Looks reasonable.
I myself also often struggle with Makefile pitfalls :)
>> 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.
Makes sense.
But I think we can make this a non-issue.
For example, we can do something like
(or (require 'compat nil 'noerror)
(require 'org-vendored-compat))
Then, if system provides compat library, we load that version.
>>> 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.
I think modules could be doable.
We can hide all the gory details under make targets, similarly to what
we do in the patch now. Then, instead of pulling compat from elpa, we
can sync the relevant git module.
Note that we historically did use modules. (I had to clean some remnants
some time ago).
> - vendor compat directly in repo
> - pros: very simple and robust. Offline friendly
> - cons: Morgan will shed a single tear dramatically
To be frank, I am not a big fan of adding and maintaining external
library files manually, but it is not too different from how we handle
upstreaming Org. So, other than your objections, I do not have anything
non-subjective to say.
> - vendor compat using submodules
> - pros: Offline friendly
> - cons: Endless frustration
I imagine that not touching that submodule except during version bumps
can help. It can be done via make target, similar to how we do ~make update~.
My usual frustration with git modules is when I have to go google yet
again how to fetch them should be addressed that way :)
> - accept current solution
> - pros: No vendoring. Easy to add more packages in future
> - cons: Online dependent.
I also feel rather uneasy about online dependence.
--
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>
