Tools in config.py

85 views
Skip to first unread message

Karen K

unread,
Jul 19, 2021, 6:28:25 AM7/19/21
to weewx-development
I wrote an extension to read the values out of an air quality device. It supplies a lot of observation types not included in the standard database schema. So I wrote a little utility to add the necessary columns to the database (or drop them from it).

Now the problem:

The utilities of WeeWX like wee_database all are started by a little wrapper shell script. But the location of that shell scripts depends on installation way like setup.py or apt-get. How can I define that wrapper script in install.py that it is put to the right place during installation?

gjr80

unread,
Jul 19, 2021, 4:47:23 PM7/19/21
to weewx-development
I’m not sure if I understand your question correctly but provided you are setting the ‘files’ parameter in install.py you can fairly much put anything anywhere in the WeeWX bin and skins tree branches irrespective of WeeWX install type (eg specifying bin/user will see the installer automatically use the correct location of either /home/weewx/bin/user or /usr/share/weewx/user depending on the install type). Of course I could be misunderstanding your question completely.

One other thing, be wary of placing code outside of the user and skins directories; files placed anywhere else in the WeeWX tree may not survive a WeeWX upgrade.

Gary

Karen K

unread,
Jul 20, 2021, 3:41:15 AM7/20/21
to weewx-development
The apt-get installation places some shell scripts (among them wee_database) into /usr/bin. That is outside the WeeWX tree. The reason for that is to place those scripts somewhere in the search path. I am not sure, where the setup.py installation puts those scripts. 

In my case there is a script like wee_database to add the observation types provided by the extension to the data_base. As the user shall call it separately it must be found within the search path.

And I have no glue, how to do that.

I placed the Python part of the script in the bin directory (not bin/user, bin only). But what to do with the shell part of the script?

airq_conf
airq_conf.py

gjr80

unread,
Jul 20, 2021, 4:30:10 AM7/20/21
to weewx-development
I see. A setup.py install puts everything in /home/weewx. Nothing is added to any paths nor are any shell scripts created. If a user wants to run, for example, wee_database they need to be in the /home/weewx/bin directory or they need to prepend a suitable path when running wee_database.

I think you are playing with fire putting files in directories other than user and skins; chances are eventually they are going to be deleted. Why not keep it simple and place your scrips in the user directory and have the WeeWX user include a path when running the command . This is not uncommon, in fact it is done to some extent when running a driver directly. Certainly saves a whole pile of heartache worrying about what a package installer does and the subtle differences across versions and distros.

From the Zen of PythonSimple is better than complex.’

Gary

Karen K

unread,
Jul 20, 2021, 5:48:30 AM7/20/21
to weewx-development
Ok. Thank you for your reply and explanation.

gjr80 schrieb am Dienstag, 20. Juli 2021 um 10:30:10 UTC+2:
From the Zen of PythonSimple is better than complex.’
That's why I put the script into the same directory as wee_database, as it has a similar purpose and a similar way of use.

But considering your explanation, I will move the Python part of the script into the user directory. And I will re-think how I can make the user find it.
 
 

gjr80

unread,
Jul 20, 2021, 7:50:23 AM7/20/21
to weewx-development
One other thought, have you considered adding the functions from air_conf.py to your airQ driver file? Not that I had any wee_database like actions to include, but when I wrote the GW1000 driver I added numerous actions (mainly displaying GW100 config data) that could be selected when the driver was run directly. So in the end the user could run the driver directly and test the driver as normal, but they could also select various other command line options to perform various other related functions. This approach can bulk out your driver file but it has the advantage of putting everything in one place with the user only needing to use one command (with various command line options). If interested the relevant section of the GW1000 driver can be found on Github here.

Gary

Reply all
Reply to author
Forward
0 new messages