I'm not sure what the log would tell you in this case. In the weewx.conf file for 4.10.1 had debug = 1 set. I have now also set that for the new install. I see nothing useful in the log file since I did that, i.e. no errors other than the ones I always see (e.g. ERROR weewx.drivers.vantage: LOOP batch try #1; error: Expected to read 99 chars; got 46 instead). It did show that an old cron job that was used to track the active tty caused multiple instances of weewx to run (FreeBSD changes the port from /dev/ttyU0 to /dev/ttyU1 or in reverse at random times). I commented that out in crontab to make sure only one instance is active. I tried one more time with the old .sdb file. Monitoring the /var/log/message file, I see no errors in the log. As before, the database doesn't update and a web page for 3:00 AM is rendered.
As the same thing happens with both weewx 4.10.1 and 5.3.1, but a clean database file works correctly with 5.3.1, so there is no problem with the basic functionality of both FreeBSD packages and weewx. P.S. I'm leaving the root based install in place, as that is no different than what I was using for 4.10.1. No warnings of the sort: Installing collected packages: pyserial, ephem, pyusb, PyMySQL, CT3, weewx WARNING: The scripts pyserial-miniterm and pyserial-ports are installed in '/home/marius/.local/bin' which is not on PATH. Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location. WARNING: The scripts weectl and weewxd are installed in '/home/marius/.local/bin' which is not on PATH. Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location. when I installed as root. Of course, I've moved everything onto the ZFS array, rather than leaving it on the boot drive. BTW: What happened to $HOME/bin? That's already in the $PATH. In my experience some of the python version requirements are out of date or too strict, i.e. often you can ignore them and everything works correctly. And yes, the venv install installed a newer version of py311-pillow than the current one provided by FreeBSD ports. So much for the install instructions for FreeBSD! I now have to redo all the customization of the skin for both the private and public versions of the web site. It's been a while since I first did that so I have to rediscover what all needs to be edited. I still need to get my all old data back! I see that 5.3.1 uses an extended schema by default, while 4.10.1 was still using the old wview schema (yes, I did start out with wview). Could there be a problem with the database using the old schema? On Sunday, March 8, 2026 at 2:56:06 PM UTC-5 Vince Skahan wrote: > Sure. The other os have python libs they install at the system level too. > Run 'pip3 list --verbose' to see what's where. > > I'm personally ok with things installing as root. I just like not > 'running' as root whenever it can be avoided. > > FWIW - I have run into the problems venv solve quite a lot. Things > needing certain versions of a library (or minimum versions thereof) and the > os freezing to something lesser. Any RHEL-like system or LTS debian is a > good example. They go for many year stability and freeze to old versions. > The venv thing is a good way to not be limited by the os vendor's choices. > > On Sunday, March 8, 2026 at 12:45:33 PM UTC-7 Greg Troxel wrote: > >> Vince Skahan <[email protected]> writes: >> >> > You generally can't avoid venvs on a modern python on a current os. >> Nobody >> > here did that. The python project forced that on everybody. >> >> That's not strictly true. pkgsrc has packages for a vast number of >> py-foo all installed in the system site-packages, and it works fine. I >> am actually running weewx that way, with the weewx code in >> /usr/pkg/lib/python3.13/site-packages/weewx and so on. >> >> In my case, the weewx progarm files are owned by root and live in the >> system. I am running it in a data directory (with config file and >> database) that is owned by a non-root user. Stepping back from weewx >> and python, this is totally normal, to use installed programs with your >> own data. >> >> <rant> >> >> I find that venvs are required because python culture says it is ok to >> have requirements as foo==x.y.z, rather than foo>=x.y. Thus, there is >> no way to have everything needed installed, and python packages with >> unreasonably specific dependencies (Home Assistant) have to be in a venv >> for isolation. >> >> The root cause of pinned deps, besides people thinking it is ok, is API >> instability within modules. >> >> </rant> >> > -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/weewx-user/1e3e0173-f581-45cd-a954-d8ec514b558dn%40googlegroups.com.
