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.
