semsql distributes ready-made config files, compiled sql files, prefixes, etc. The job of building these belongs to the release manager. It is orchestrated by build.Makefile.
When a user invokes make foo.db, it uses the same Makefile. In general, only the intended targets, but it seems there are some circumstances that may trigger the release artifacts to be remade. This is not good obviously a user action should not alter files in /Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packages or wherever.
This partially explains some of the odd behavior seen here: #71
The solution here is to simply split the release managers makefile from the package-distributed makefile used by the user
(of course, using a makefile at all is bad, and this is just temporary until we replace rdftab with something we can speak to via python, see #41)
semsql distributes ready-made config files, compiled sql files, prefixes, etc. The job of building these belongs to the release manager. It is orchestrated by build.Makefile.
When a user invokes
make foo.db, it uses the same Makefile. In general, only the intended targets, but it seems there are some circumstances that may trigger the release artifacts to be remade. This is not good obviously a user action should not alter files in/Library/Frameworks/Python.framework/Versions/3.9/lib/python3.9/site-packagesor wherever.This partially explains some of the odd behavior seen here: #71
The solution here is to simply split the release managers makefile from the package-distributed makefile used by the user
(of course, using a makefile at all is bad, and this is just temporary until we replace rdftab with something we can speak to via python, see #41)