I know am a bit late to the party. I am also no Python expert and I know
that I will be able to work with any new packaging/install. But, I want to
note my workflows that are super easy with today's packaging/install
1. Debugging base WeeWx code
1. Git fork and clone
2. Copy known weewx.conf
3. Update code as necessary
4. Checkin and create pull request
Depending on how WeeWX is installed, between 3 and 4 I believe I would need
to do 1 or more diffs to get the updated code back to my git repository.
After that, I should probably do another install/test to make sure all my
updates are in my repository.
2. Extension development
1. Download setup.py install type of WeeWX version and untar it
2. Install versions of python via pyenv
3. Install prerequisites via pip in each pyenv environment
4. Via PYTHONPATH and PYENV_VERSION settings run unit tests and
integration tests for each environment. Locally this weewx4/python2.17,
weewx4/python3.5, weewx4/python3.6, weewx3/python2.17. In the CI
environment it is weewx4/python2.17, weewx4/python3.5, weewx4/python3.6,
weewx4/python3.7, weewx4/python3.8, weewx4/python3.9,
weewx3.7.1/python2.17, weewx3.9.2/python2.17.
I care less about the CI environment, because its all automated. But
suppose someone reports a bug against my extension and weewx4.1. Today, I
download weewx4.1. Set the PYTHONPATH and PYENV_VERSION and easily run unit
tests and integration tests against 6 versions of python. If I understand
correctly, assuming I want to keep my install of weewx4.0/python-x, I'd
have to do another install of python-x and weewx-4.1 into it.
Again, I know I can accomplish what I need with new packaging/install of
WeeWX. But, as an extension writer right now it super easy to support the
matrix of WeeWX versions and python versions.
- rich
Again, I know I can accomplish what I need with new packaging/install of
WeeWX. But, as an extension writer right now it super easy to support the
matrix of WeeWX versions and python versions.
On Saturday, 9 May 2020 22:13:15 UTC-4, Tom Keffer wrote:
>
> At this point, I think we've discussed this enough and it's time to
> experiment. From the discussion, I'd say the requirements are:
>
> 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. I'm not real keen on having the libraries buried
> deep
> in this directory, but I'm willing to try it and see how it feels.
> 2. Ability to install in "standard" locations.
> 3. Skins, and the user directory cannot be touched by an upgrade.
> 4. weewx.conf gets automatically patched by an upgrade. This is a big
> feature of weewx over the standard package upgrades, which merely ask a
> user if they want to "merge" their old config file with an incoming, new
> config file.
> 5. The modules 'user' and 'schema' would have to move to avoid name
> collisions, to weewx.user and weewx.schema, respectively. To maintain
> backwards compatibility, dynamic imports would automatically try their new
> locations.
> 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>.
>
> Did I miss anything?
>
> Any volunteers?
>
> -tk
>
> How about a volunteer?
>
>
>
> On Sat, May 9, 2020 at 8:54 AM Greg Troxel <g...@lexort.com <javascript:>>
> wrote:
>
>> Tom Keffer <tke...@gmail.com <javascript:>> writes:
>>
>> > If I install using
>> >
>> > *pip3 install ansible --root=/home/ansible --prefix=""*
>> >
>> > I get
>> >
>> > /home/ansible
>> > ├── bin
>> > │ ├── ansible
>> > │ ├── ansible-config -> ansible
>> > │ ├── ansible-connection
>> > │ ├── ansible-console -> ansible
>> > │ ├── ansible-doc -> ansible
>> > │ ├── ansible-galaxy -> ansible
>> > │ ├── ansible-inventory -> ansible
>> > │ ├── ansible-playbook -> ansible
>> > │ ├── ansible-pull -> ansible
>> > │ ├── ansible-test
>> > │ └── ansible-vault -> ansible
>> > └── lib
>> > └── python3.5
>> > └── site-packages
>> > ├── ansible
>> > ├── ansible-2.9.7-py3.5.egg-info
>> > └── ansible_test
>> >
>> > Close to what we're looking for --- you'd have to specify a rather
>> > complicated PYTHONPATH when running 'ansible'.
>>
>> Yes, but if you had created a venv, and then run the program with the
>> python in the venv, it would all work.
>>
>> If weewx installed in $perfix/lib/pythonN.Y/site-packages/weewx/, then
>> it would be doing the normal thing, aligned with above. If that prefix
>> is the same prefix as python was built with -- which is also the normal
>> thing -- then it will all work fine.
>>
>> > I almost always run weewxd from a git repository, and just specify the
>> path
>> > to the configuration file weewx.conf, which is off somewhere else.
>> Because
>> > its modules are located under the executable, it can find its own
>> > libraries. Specifying a PYTHONPATH is not necessary. Kind of 'node'
>> style.
>> > Frankly, I don't know why more python programs aren't configured this
>> way.
>>
>> Being able to do that from git doesn't seem in conflict with the install
>> using standard paths.
>>
>> > Both weewx proper and extensions depend on these names. Right now, the
>> are
>> > usually accessed through dynamic loading, specified by the configuration
>> > file. For example, a driver might be configured as:
>> >
>> > [Acme]
>> > driver = user.acme
>> > port = /dev/ttyUSB0
>> >
>> > So, we would either have to patch the configuration file to change all
>> > instances of user.acme to weewx.user.acme, or have a fancy import which
>> > tries to import weewx.xxx first, then, if that files, import xxx.
>>
>> It seems easy to have the code that does import check if the
>> driver/whatever
>> starts with weewx., and if not 1) warn and 2) prepend it. That
>> provides for a soft transition with little pain.
>>
>> > I don't care what it's called. What I'm looking for is
>> >
>> > *pip install weewx*
>> >
>> > and the program ready to go, without a second "configuration" pass. But,
>> > this requirement is not absolute. We already have a configuration
>> utility,
>> > so requiring the user to run it after installing is not so bad. But, I
>> > guarantee users will not always do it, and it will be a source of
>> support
>> > questions!
>>
>> I am actually looking for this NOT to be the case. In dealing with
>> packaging systems, installation of software is done to a staging
>> diretory, and then tarred up, laster untarred, and then that system is
>> configured. So it's great to have the config step invokable from the
>> installed copy of weewx, but in a packaging system I need to disable
>> that from the regular install.
>>
>>
>>
>> I continue to not understand the sharp focus on pip proper. The real
>> compatibility issue is that setup.py installs to non-standard paths that
>> don't play well sharing a prefix with packaging systems and other
>> installed python software. Once that's resolved then pip should just
>> work, modulo installation and post-installation config being separable
>> steps -- even if users are directed to run a script that does setup.py
>> and then config, so it amounts to the same steps as now.
>>
>
--
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/25c18459-1d14-46e0-b824-496e59cbd9a9%40googlegroups.com.
