All of the packages WeeWX uses are very mature. It's the same set of pre-requisites that I started with 10+ years ago. HOWEVER, not all of them are pure Python. For example, Cheetah uses an internal C library, _namemapper, for performance. It's name follows the wheel convention (for example, it's _namemapper.cpython-35m-x86_64-linux-gnu.so for Python 3.5 on an x86 64-bit machine), so we'd have to include all of those, too. Ditto with PIL, and maybe ephem.
-tk On Sun, May 10, 2020 at 1:27 PM Vince Skahan <[email protected]> wrote: > On Sunday, May 10, 2020 at 12:36:58 PM UTC-7, Greg Troxel wrote: >> >> Vince Skahan <[email protected]> writes: >> >> > A good example is trying to do a dpkg or rpm that requires >> python3-cheetah >> > when your distro does not 'have' such a package. If you install >> cheetah >> > with pip as a second way to get it onto the system, if your package >> isn't >> > smart enough to support that, a package installation will fail and you >> > would have to use a --force or a --ignore-dependencies (or the like) >> switch >> > to force the package to install. Those options cause risk too, and a >> > non-linux person won't understand the risks nor how to deal with >> adventures >> > if they pop up. >> >> That sounds like a broken packaging system. In order to have weewx, it >> first has to have all the dependencies. People doing package >> maintenance deal with this as part of package creation. >> >> >> > It's not a broken packaging system, it's operating system differences and > trying to use one package to handle all os variants+versions with one > package. I've battled this for 15+ years in $work. > > A python app packaged in rpm format would run on centos 5, 6, 7, 8 just > fine but some versions have corequisite library xyz and some don't. That > would mean the rpm works in some os+version combinations, but not all. > Confusing to the user when a rpm refuses to install and the os gives the > user a cryptic not-helpful message. > > Same with dpkg installations. We see differences between ubuntu and > debian variants, versions of each os variant, and other dpkg-compatible > operating systems (Mint etc.) > > I can think of three ways out of this os+variation problem: > > - (1) smarter packages - you can certainly build rpms with a lot of > conditional logic based on os+version combinations. I dunno about dpkg. > Downside here is you're always catching up to things people find as the os > 'standard' moves due to the upstream vendor > - (2) stop using the os's python modules. Bundle at least the add-on > modules weewx needs 'with' weewx core, located under the weewx tree > someplace. Fix up PYTHONPATH or the like as needed. > - (3) build a zillion packages and host a zillion repos. Have people > pick the right repo for their os variant. See > https://rpms.remirepo.net for one good example. Scroll down in the > page for all the os versions+variants he supports. Amazing. > > Option-1 is too much catchup, and too painful > > Option-2 is how big apps like splunk and puppet do it. They bundle the > interpreter+libs they need under their tree. If you think about it, it's > also how RHEL chose to work the python issue for RHEL-8. They don't use > the /usr/bin/python3 stuff. They have their own internally-used-only path > with the things 'they' need. > > Option-3 is how you'd do it in a CI/CD/autotest world. The Remi repos are > a great example of this. It's certainly technically possible to build an > infinite number of os+version package variants via Docker and Github hooks > if we wanted to go that path. > > FWIW - I lean to option-2 - just package what weewx needs 'under' the > weewx tree the dpkg or rpm installs. Don't use the os python libs at all. > > The downside of option-2 is what would we do if a security vulnerability > appears in one debian-ish variant (only) of configobj, as a hypothetical > example. Would you rerelease weewx for just that os+version (perhaps, bump > a revision number on the same weewx-4.0.0 base name so yum update sees > something needing updating) ? All those what-if's need to be thought of. > > Anyway - personally I really like option-2 as it gets us out of the "did > my os provide the expected package for python3-whatever" problem. > > > -- > 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/087f1bf9-0d44-44c4-989e-ad1e10f59b10%40googlegroups.com > <https://groups.google.com/d/msgid/weewx-development/087f1bf9-0d44-44c4-989e-ad1e10f59b10%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAPq0zEChA%3DKCTOs35W4pM4efUHD0Mz%3D8qynwKMYw6xNeipFfsg%40mail.gmail.com.
