At this point, I think we've discussed this enough and it's time to experiment. From the discussion, I'd say the requirements are:
1. Ability to install into one directory, such as /home/weewx. It's OK if it takes some contorted setting of install directories in order to do this, but I like having all state, all libraries, all code, in one spot. It makes my life easier. I'm not real keen on having the libraries buried deep in this directory, but I'm willing to try it and see how it feels. 2. Ability to install in "standard" locations. 3. Skins, and the user directory cannot be touched by an upgrade. 4. weewx.conf gets automatically patched by an upgrade. This is a big feature of weewx over the standard package upgrades, which merely ask a user if they want to "merge" their old config file with an incoming, new config file. 5. The modules 'user' and 'schema' would have to move to avoid name collisions, to weewx.user and weewx.schema, respectively. To maintain backwards compatibility, dynamic imports would automatically try their new locations. 6. Support for our "standard platforms," which generally includes the platforms listed in Matthew's compatibility matrix <https://github.com/weewx/weewx/wiki/weewx4-compatibility-matrix>. Did I miss anything? Any volunteers? -tk How about a volunteer? On Sat, May 9, 2020 at 8:54 AM Greg Troxel <[email protected]> wrote: > Tom Keffer <[email protected]> writes: > > > If I install using > > > > *pip3 install ansible --root=/home/ansible --prefix=""* > > > > I get > > > > /home/ansible > > ├── bin > > │ ├── ansible > > │ ├── ansible-config -> ansible > > │ ├── ansible-connection > > │ ├── ansible-console -> ansible > > │ ├── ansible-doc -> ansible > > │ ├── ansible-galaxy -> ansible > > │ ├── ansible-inventory -> ansible > > │ ├── ansible-playbook -> ansible > > │ ├── ansible-pull -> ansible > > │ ├── ansible-test > > │ └── ansible-vault -> ansible > > └── lib > > └── python3.5 > > └── site-packages > > ├── ansible > > ├── ansible-2.9.7-py3.5.egg-info > > └── ansible_test > > > > Close to what we're looking for --- you'd have to specify a rather > > complicated PYTHONPATH when running 'ansible'. > > Yes, but if you had created a venv, and then run the program with the > python in the venv, it would all work. > > If weewx installed in $perfix/lib/pythonN.Y/site-packages/weewx/, then > it would be doing the normal thing, aligned with above. If that prefix > is the same prefix as python was built with -- which is also the normal > thing -- then it will all work fine. > > > I almost always run weewxd from a git repository, and just specify the > path > > to the configuration file weewx.conf, which is off somewhere else. > Because > > its modules are located under the executable, it can find its own > > libraries. Specifying a PYTHONPATH is not necessary. Kind of 'node' > style. > > Frankly, I don't know why more python programs aren't configured this > way. > > Being able to do that from git doesn't seem in conflict with the install > using standard paths. > > > Both weewx proper and extensions depend on these names. Right now, the > are > > usually accessed through dynamic loading, specified by the configuration > > file. For example, a driver might be configured as: > > > > [Acme] > > driver = user.acme > > port = /dev/ttyUSB0 > > > > So, we would either have to patch the configuration file to change all > > instances of user.acme to weewx.user.acme, or have a fancy import which > > tries to import weewx.xxx first, then, if that files, import xxx. > > It seems easy to have the code that does import check if the > driver/whatever > starts with weewx., and if not 1) warn and 2) prepend it. That > provides for a soft transition with little pain. > > > I don't care what it's called. What I'm looking for is > > > > *pip install weewx* > > > > and the program ready to go, without a second "configuration" pass. But, > > this requirement is not absolute. We already have a configuration > utility, > > so requiring the user to run it after installing is not so bad. But, I > > guarantee users will not always do it, and it will be a source of support > > questions! > > I am actually looking for this NOT to be the case. In dealing with > packaging systems, installation of software is done to a staging > diretory, and then tarred up, laster untarred, and then that system is > configured. So it's great to have the config step invokable from the > installed copy of weewx, but in a packaging system I need to disable > that from the regular install. > > > > I continue to not understand the sharp focus on pip proper. The real > compatibility issue is that setup.py installs to non-standard paths that > don't play well sharing a prefix with packaging systems and other > installed python software. Once that's resolved then pip should just > work, modulo installation and post-installation config being separable > steps -- even if users are directed to run a script that does setup.py > and then config, so it amounts to the same steps as now. > -- You received this message because you are subscribed to the Google Groups "weewx-development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-development/CAPq0zEDvA1SKJK6c5iEJ%3DbVpyBXgQ_4FiG-HPuNmX5KJSU%3Dqzg%40mail.gmail.com.
