Tom Keffer <tkef...@gmail.com> 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 weewx-development+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-development/rmiblmx14ut.fsf%40s1.lexort.com.
