Ihor Radchenko <[email protected]> writes: >> 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.
No, this does not sound good. It should only be (require 'compat), and the build scripts should make sure that Compat is available on the load path, either the Emacs Compat shim, a Compat installed as package or a vendored Compat. Otherwise you will create an incentive for distributions to install the org-vendored-compat as part of the distributions package, and this is clearly undesired. The only purpose of the vendoring should be that you have the source of Compat is available of "offline use" inside the repository, such that you can develop with a cloned version of the Org repository without installing anything else, without cloning another repository and without cloning a git submodule. Daniel
