Morgan Smith <[email protected]> writes: >> 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? > > Seems like an easy thing to add. Might as well. Maybe we should have a > "EMACS_LOAD_PATH" and "EMACS_LOAD_PATH_EXTRA" variable.
I am not sure if we should limit things to load path. If we add such environment variable, may as well allow passing arbitrary options. >> 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 :) > > I'm liking this idea more and more. Required git submodules are really > annoying because it adds another layer of friction to first build that I feel > like git should be smart enough to do for me. However, this is an optional > git > module so now the git defaults actually make sense in this case. > > If we don't meet the required dependencies then my "org-dependencies.el" > script > will be able to communicate to the user what commands to run (just as it > currently tells the user to run "uppkg"). So no google required! > > When we do a version bump we will also increase the version number that is > checked in my "org-dependencies.el" script so the user will once again be > prompted with what commands they need to run. +1 > The only downside I could conceive of is if a user uses the git > submodule to build org and then runs that byte-code locally on their > system with their system compat which could be of a different version. > Honestly even if people do this they are unlikely to experience any > negative effects. The ideal solution would be for those people to build > with "EMACS_LOAD_PATH_EXTRA" set as mentioned earlier. We can just document this in https://orgmode.org/manual/Installation.html By default, we recommend a simple make autoloads (no byte compilation) for Git. (And I just got to know about https://orgmode.org/worg/dev/org-build-system.html page o_O. This gotta be in testing/README.org) >>> If the code is downloaded as tarball, I strongly recommend to check it >>> against a sha256 hash. See for instance: >>> >>> https://github.com/minad/doom-on-emacs/blob/9d5929335c4080699a2daa153ace2996c905008a/Makefile#L17 >>> >>> This way you would get similar guarantees. >> >> That would correspond to setting `package-check-signature' to t in the patch. > > Do we trust git fetch? If I go ahead with a submodule approach do I have to > worry about this? git should verify https certificates. We may additionally verify commit signatures. Daniel signs his commits. -- 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>
