As I said earlier, I put quite a bit of time trying to get pip to work. You can see the results in the 'pip' branch <https://github.com/weewx/weewx/tree/pip> of the repository. NB: it's a work in progress, so the branch is not a "finished" dead end, but rather an "idea" dead end. It follows your ideas: executables and libraries are in different locations, and the install destinations can be changed via setup.cfg or command line arguments to setup.py. I couldn't get it to work, but this was a couple months ago, and I don't recall the details, although it revolved around weewx being an application, not a library.
In fact, I would appreciate it if you could point me to any non-trivial application that pip installs. I couldn't find any. Just libraries. Requirements for a pip install: 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. 2. Ability to install in "standard" locations. 3. If we install in standard locations, and if the names of the weewx modules are not changed (and I don't think they should be), then there is a risk of a name collision for common names like 'schema' and 'user. A strategy for this. 4. A "one pass" install, rather than pip, followed by invoking yet another program that asks the user for station settings. Right now, we do this by invoking wee_config with appropriate parameters from within setup.py (this part is not finished in the pip branch). 5. Pip allows you to upload a given version number only once. This would require an automated version naming tool, otherwise it's a righteous pain the butt. I don't know anything about tox. Can it do something like this? 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>. I am very open to switching if a good value proposition can be made for doing so, and if you, or someone, can own the results. Definitely no NIH on my part around this! -tk On Tue, May 5, 2020 at 11:24 AM Till Maas <opensou...@till.name> wrote: > On Mon, May 04, 2020 at 04:53:13PM -0700, Vince Skahan wrote: > > > > Certainly. Too many scope-increase meetings on the project from hell at > > work I guess. Sorry if I jumped the gun :-) > > > > Anyway, I guess I always try to think "*it it was my money funding this, > > would I invest here at this time*", because time+blood pressure are > things > > we all have limited budgets for too. > > > > So I guess I'd be interested in understanding: > > > > - What problems does pip solve ? What problems does it cause ? > > pip is the standard installer for python modules. It allows to > > Install python tools (system-wide or per-user), tracks what it installed > and allows to remove and uninstall the files. Also it supports > dependencies, so that it can install all the necessary python modules > that are required (for example configobj, cheetah, pil ...) > > Together with tools like venv, it allows to create custom python > development versions in specific directories. This allows to scope the > installation even finer. For example, I could have a different > development environment for weewx than for another project that might > require different python versions or module versions. > > Then with tools like tox, one can easily create different test > environments to run unit tests or static code analyzers for different > python versions. This allows to check for unused variables, code style > violations, missing/unnecessary imports etc. > > This could all be included in a system that then automatically performs > these checks for each change to the code. > > I would like to use this for the driver that I want to develop. Since > every other module than weewx follows the standard approach, I can > specify them as requirements for the project and it the system installs > them automatically without any special code for weewx. > > Consider that all modules would use their custom installation method, > then it would need quite some effort to install all the modules that > weewx uses (configobj, cheetah, pil, serial, usb, pip, ephem, ...). > > > - Same questions re: where things are installed to. How does > switching > > the installed locations help/hurt the as-is ? > > By using the standard method, it would be also very easy to package for > different distributions, since they are optimised for the default > approach. For example Fedora supports automatically generating the > python dependences based from the information of the pip-compatible > package. Currently, the weewx spec contains a manually created list of > RPM dependencies. Also the installation instructions would be simpler > because it would just set the default paths for the distribution. I > assume it would be similar for other distributions since using a common > format makes it easier for distributions to simplify things. > > Since I do not know the reasons, why weewx does differently, we are > having this conversation to see if it is feasible. From my > understanding, the biggest hurt would be to learn the new paths for > existing developers. For new developers, they would be hurt less because > weewx works like other existing python projects. > > > - Does switching to pip change how painful (or not) it is to release > an > > updated distribution ? Digitally sign them ? Etc.... > > My understanding is that it makes things easier for packaging since it > will make weewx be more like other projects. > > > - Does switching to pip alter the '*git pull ; python3 setup.py build > ; > > python3 setup.py install*' kind of use case the folks more on the > > developer bleeding edge side tend to work ? > > It should still work. If there are interactive steps that are done as > part of the install script, they might need to run a different, tool, > too. > Otherwise, you should be able to benefit from using pip with this, too: > git pull; pip install --user --upgrade . > > Also, python3 setup.py install* might not remove files from older weewx > installations that would not be installed anymore but could cause > problems. So this might also change. > > > - Does it alter anything re: extension installation tools or > extension > > structure ? > > It is not necessary to change this but a logical next step would be for > (future) extensions to also be pip-installable instead of using a custom > weewx method to copy files. > > > Lots of moving parts in weewx's ecosystem to think about.... > > Yes, thank you for providing this detailed feedback. > > Thanks > Till > > -- > 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/20200505182444.GF16242%40genius.invalid > . > -- 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/CAPq0zEAY%2BZ3kApur%3DyrFmUXr5tXxE9TdWFVuWc4cDN9vo0qK%3DQ%40mail.gmail.com.
