Tom Keffer <
tke...@gmail.com> writes:
> The problem is not the configobj format, it's the future readonly nature of
> Python installs. The config file (and skins) are considered "data", and the
> only way to include "data'' is within a Python package. That package might
> be in a zipfile or Python egg, hence its readonly nature.
I'm writing from the pkgsrc viewpoint, which is really a set of norms
adapted from coping with 10s of thousands of packages. (I think the
Debian situation is pretty similar, but I'm not entirely clear on the
details. Of course prefix = /usr in that case, which is normal in
GNU/Linux and not ok in BSD, where that's the base system only.)
packages have executables, libraries, and included data files, and all
of these are basically unchanging. If you wish them to be different,
you make a commit to the source repo for the package, and then make a
distfile and use that in a pkgsrc package. Or you apply at patch at
build time, but the point is you change the sources. Executables go
in $prefix/bin, normal libraries in $prefix/lib, and python modules in
$prefix/lib/python3.N/site-packages, and text files in $prefix/share.
packages have config files, and they go in $prefix/etc. But because
of packaging, they don't -- they are installed in someplace
$prefix/share/examples/$PKGNAME/$pkgname.conf and treated as read-only
there. They are declared as config files so a fresh install puts a
copy in $prefix/etc or $prefix/etc/$pkgname. On uninstall, if it
matches still, it's removed. If not, it's left. An install when the
file already exists doesn't change it.
packages when they run will store data, and that goes in
$prefix/var/$pkgname, or /var/$pkgname, depending on how the packaging
system (globally) is configured.
So I think regularizing weewx into this is a good step.
> Furthermore, installs can only be done within "sys.prefix
> <
https://docs.python.org/3/library/sys.html#sys.prefix>". You can't just
> roam around the file system and install things wherever you like. Hence,
> a more unixy setup could not be done with pip, even if we wanted to.
I am not sure what you mean; pip can install executables to $prefix/bin,
and those executables can read config files in $prefix/etc. Staying
within --prefix seems unixy enough, but maybe you mean something even
more agile.
> While I was at first put off by this decision, I can see their point. For
> one thing, it means sudo is no longer necessary. You can also install into
> a virtual environment as easily as into the system's python.
And, you can meet packaging system norms which require staying within
the packaging system prefix.
I'll also note that you can use something like autoconf and have that
run setup.py or whatever as a sub-step, for a program that is not pure
python. Probably that does not make sense here.
And, my usual plea: there is a fairly small set of standard build
systems. Packaging systems (and individual humans) have to learn to
deal with each of them. It's best to do something a lot of other people
are doing.
> Regarding the format, I suppose we could move to a different format besides
> configobj, but it has served us well --- I don't see a compelling reason to
> change. For one thing, changing would break a *lot* of things.
I think it would be good to clean up the round-tripping issue, even if
weewx never writes. If we use configobj, then all files intended to be
read by it should be in its canonical form.
> See this thread <
https://github.com/pypa/setuptools/discussions/2648>. It's
> hard to follow without spending some time in Python packaging land, but it
> discusses these issues.
Thanks; that helps me understand a little.
Regarding setup/wizards, I don't think there is anything wrong with
having a program that you run and asks questions or whatever and then
outputs a new weewx.conf in the current directory. The user can then
put it in $prefix/etc.