> Not sure, what exactly the application needs to be to be non-trivial.
> This is a rather big project with several CLI tools:
> https://pypi.org/project/ansible/
>
>
Oooh, that's a good example. Largeish, and it installs with a simple "pip
install ansible". Wish I had found it sooner.
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'.
> Requirements for a pip install:
> >
> > 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.
>
> In my opinion, it would be nice to be able to run weewx from a GIT
> working copy and it being pip-installable does not contradict this. So
> in general this should work. Not sure, if you also consider helper
> configuration like logrotate or init config to be in that directory, but
> I guess, not.
>
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.
>
> > 2. Ability to install in "standard" locations.
> > 3. If we install in standard locations, and if the names of the weewx
> > modules are not changed (and I don't think they should be), then
> there is a
> > risk of a name collision for common names like 'schema' and 'user. A
> > strategy for this.
>
> What is depending on these names? Are these only extensions that weewx
> will install and import/execute or also something external? What
> locations do things expect them to be? There could be compat package that
> contains files in /usr/share/weewx/ that provide the new names. Also the
> python path could be adjusted for extensions that weewx loads.
>
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.
> > 4. A "one pass" install, rather than pip, followed by invoking yet
> > another program that asks the user for station settings. Right now,
> we do
> > this by invoking wee_config with appropriate parameters from within
> > setup.py (this part is not finished in the pip branch).
>
> As long as the "one pass" install does not need to be called setup.py,
> it would be rather easy to add a helper like "local-install" that will
> then call setup.py/pip and the script to configure the station settings.
> Would this be enough?
>
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!
> 5. Pip allows you to upload a given version number only once. This
> would
> > require an automated version naming tool, otherwise it's a righteous
> pain
> > the butt. I don't know anything about tox. Can it do something like
> this?
>
> Not sure, what the problem is, here. You will only release for example
> 4.0.0 only once, wont't you? tox is not the tool to address something
> like this, it simplifies running commands for different python
> versions/environments.
>
No problem. I just found it was tedious to have to always assign new
version numbers while testing the pip installation machinery. But, once you
get it working, it becomes less of a burden.
>
> > 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>.
>
> This is not a problem. I am a little bit sad that Fedora is not
> considered a standard platform, though. ;-)
>
Matthew would know better than me, but the vast majority of users use
CentOS, not Fedora.
-tk
--
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/CAPq0zEC-S3piAKWRN%2BqhVHcL%3DtXtenQx9r%3DN60vJ0HHQqXkPVA%40mail.gmail.com.
