On Nov 7, 2024, at 10:30, David E. Wheeler <david@justatheory.com> wrote:
> Last week I tried to integrate all the ideas into this thread and the previous[1] into a single proposal that
attemptsto work through all the implications and issues. I’ve drafted it as a blog post[2] and plan to publish it next
week,following some more feedback. Would appreciate comments, corrections, and any other general feedback:
>
> https://github.com/theory/justatheory/pull/7
Got some good feedback on this, in particular about how I might be overthinking separate destinations for core vs.
package-installedvs. user-installed extensions. The RFC proposes separate directories and variables for
core/vendor/siteextensions, borrowing the idea from various dynamic language systems.
I came to this thinking that it was important to keep core (contrib, PL) extensions separate from non-core extensions,
andif so, it’d be useful to have other defaults so that `make install` would go to the right one (site by default).
But maybe it’s not necessary? If there are no extensions by default, perhaps it doesn’t matter?
But of course there are some by default. I just ran `make all && make install`, and `share/extension` contains files
forplpgsql (and plperl, but I presume it could be separated). Meanwhile, `lib` is full of a _ton_ of files.
Would it not be beneficial to have by-default empty directories into which extensions and modules are installed that
don’tcome with core? Or should they *all* be considered one thing? If the latter, perhaps truly core modules should be
storedseparately?
Best,
David
