Hi, On Sat, May 09, 2020 at 07:12:46PM -0700, Tom Keffer wrote: > 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.
What exactly is happening here? > 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. There are also six.py, which I guess could be removed and users should be asked to install it from their distribution or via pip and daemon.py (which I guess could be moved in the weewx package). The user directory is the directory where wee_extension adds new extensions, isn't it? On first thought, the best approach for me would be that the recommended way to install extensions would be that they use pip as well for installation. Everything that wee_extensions installs, would be best moved to /var/lib/weewx/user or similar to ensure that it does not conflict with the packaged files from weewx. Seems like it would be $HOME/.local/share or $XDG_DATA_HOME if installing per-user. There does not seem to be a better counter part for /var/lib. > 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? The items in ./util are not managed by setup.py, are they? > Any volunteers? I would like to contribute. My challenge is that I am rather new to weewx, so I do not have the full picture, yet. Thanks Till PS: Tom, I resent this because I forgot to add the list in my first reply. > > -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. -- 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/20200510153712.GA25070%40genius.invalid.
