Provide wheel package

[Rafficer]

Currently, pythondialog is only available as a tar.gz archive on PyPI. The problem with this is that it requires the end user to have the setuptools package installed.

Providing a wheel file would solve this.

All that would need to be done is replace

from distutils.core import setup

in setup.py with

from setuptools import setup

And then package it with python setup.py bdist_wheel

[frougon]

Hi Rafficer,

Thanks for the suggestion, but could you please be more precise about your use case? Because it is not true, AFAICT, that installing pythondialog requires one to have the setuptools package installed. Indeed, being packaged with distutils, pythondialog can be installed with the ./setup.py install method described in the INSTALL file (see “Old way, without pip” in the file).

When installing with pip, I believe setuptools is indeed required, but since setuptools is always available in venvs (AFAIK), the only problematic cases for installation via pip would be when trying to run pip outside a venv... which in most cases is not a good idea. So, could you elaborate a little bit on your use case?

Regards

[Rafficer]

You can find the use case in this repository: https://github.com/ProtonVPN/protonvpn-cli-ng

This package requires root access (it handles VPN connections). Installing it in a virtualenv would be inconvenient for the end user as the executable couldn't be called without too many steps. Also, the installation would go from 2 simple steps to 4 or 5 steps.

[frougon]

Mmm, your README.md gives instructions like sudo pip3 install protonvpn-cli. There are many places on the web advising against running pip install as root, because this is likely to interfere with Python packages installed by the distro package manager (rpm, dpkg, etc.). This is so bad that Debian patched the pips they ship to behave (by default) as if --user had been passed. But I believe calling pip install as root may still cause mess on other distros.

The venv approach is really simple, and when a package has been installed inside a venv (using venv-base-dir/bin/pip install ...), Python scripts in venv-base-dir/bin have a shebang allowing to directly call such scripts without doing anything special (there is no need to “activate” the venv), resulting in them being run with the Python interpreter and packages from the venv. On systems that don't support shebangs, you can call venv-base-dir/bin/python /path/to/script arguments... to achieve the same. You can read about all this here, for instance.

So, unless you've already done so, I'd suggest you to try the venv approach and see if it really makes thing more difficult. I think the barrier is mainly psychological... which doesn't mean it doesn't matter—especially when it comes to users. Anyway, I'll read up on wheels a bit more and may upload one if the necessary changes don't cause any noticeable inconvenient. However, I intentionally delayed transition to setuptools in the past because, contrary to distutils, it isn't part of Python releases. AFAIK, this is still the case, and the same goes for pip (despite the ensurepip module). That said, pip being widely available, I don't close the door and may reconsider this.

[Rafficer]

Thanks for all this info. I know that running pip as sudo is a bad idea, but it's the only way where imo every user, no matter how tech-savvy, has issues with installing

I'll just use the summary of the article and comment on that:

If you want to make a package available to all users of the machine, you have the right permissions, and the package is available, then use your distribution's package manager (apt, yum, pacman, brew, etc.).

Well, not available. Making it available takes years and providing repos for almost all distros is also unfeasible

If you don't have root permissions or the OS package manager doesn't have the package you need, use pip install --user and add the user installation directory to the PATH environment variable.

As root is required to run it, it would lead to a command not found error message when using sudo as the user specific bin folders are not in PATH with sudo. This means either symlinking to a global path folder or appending the folder to roots PATH. Both already too much for non tech-savvy users

If you want multiple versions of the same library to coexist, to do Python development, or just to isolate dependencies for any other reason, use virtual environments

I know that using virtualenvs in general isn't hard, but it's still too hard for the average user. It also requires symlinking to use it anywhere in the system and to update the package you still need to activate the virtualenv

[frougon]

Replying to your last paragraph: with venvs, you can directly run venv-dir/bin/your-script which should have a proper shebang if installed by pip inside that venv. Concerning the symlinking, I assume you meant creating a symlink from somewhere-in-PATH to venv-dir/bin/your-script. Right. However, regarding the updates, I see no need to activate anything:

venv-dir/bin/pip install --upgrade yourpackage

Isn't it enough?

Note: by venv, I mean the thing brought by python3 -m venv some-dir (not exactly the same as virtualenv).

[Rafficer]

Well, yeah it would be enough, but how do you explain to users that they need to enter the full path to pip inside the venv, but nobody can tell them for sure what that path is, anybody can install it anywhere.

Doing this sounds like a support nightmare...

[frougon]

Yes, it is more work to explain. But not messing with the installation managed by the Linux/whatever distribution is highly desirable IMHO. There are not so many good things that come at no cost...

As for the “how do you...”, you can see here a place where I explained the basic concepts to users wanting to install FFGo with pip inside a venv. It is effectively a mini-tutorial on venvs and pip.

That text is certainly not perfect. I believe the best way to make things accessible in such cases is to start with an example “for the impatient” that gives the 4-or-so needed commands with hardcoded paths, and doesn't delve into explanations (→ learning by example). People can mentally extract the base path of the venv and naturally figure that it can be replaced by whatever they want. Then you can write a longer text with possibly more abstract contents (e.g., a placeholder for the venv base dir) and real explanations. Of course, it's up to you to decide in the end, since I won't be the one doing the support. :-)

[kaplun]

Sorry, while trying to following, is there an actual blocker to release a wheel package which is the new recommended standard for distributing Python packages? That would then allow the final choice to developer who depends on this library on how to really ship it.

[frougon]

I'm not saying it is a blocker, but this would require a switch from distutils to setuptools. Currently, you can install pythondialog from source without having setuptools installed. After the switch, this wouldn't be possible anymore, AFAICT.

[frougon]

I will switch the packaging to setuptools and upload a wheel on PyPI (main reason: blend well with the rest of the Python ecosystem). People who can't install the wheel with pip should be rare nowadays. They should be able to build from source (python3 setup.py sdist) after installing setuptools, and for those who can't do that either for some reason, the only installation needed is to copy dialog.py to the appropriate place (e.g. base_dir/lib/python3.7/site-packages/dialog.py). Wheel files (with .whl extension) are zip archives, so it will be possible to extract dialog.py with unzip from the .whl file, among other possibilities (download the file from the Git repository, extract it from a source tarball...).

First tests with the new packaging ran fine. Due to RL constraints and since there are a few documentation files to update for this change, a few days may be needed before this gets into a public release.

[Rafficer]

Sounds great. Thank you for your engagement! :)

[frougon]

@Rafficer You're welcome. You are using Python 3, right? Because I think it's about time to drop support for the Python 2 backport...

[Rafficer]

Sure do, it would be irresponsible starting a project with a Version dying in a month :smiley:

[frougon]

All right, fully agreed. :-)

The packaging has been switched to Setuptools in commit 88a3f0b45e81aaecf3a85bcf8b8d8ce907fbe29d and release 3.5.0 in wheel format is now available on PyPI. This should close this issue.

The OpenPGP signatures are a bit hidden by current PyPI, but they are available. Just add .asc to the URL for either the sdist or the .whl file. Example: OpenPGP signature of the 3.5.0 wheel file.

[Rafficer]

Perfect, thank you!!

[frougon]

Hi,

FYI, I've released version 3.5.1 and updated the Python 2 backport the same way. Thus, the backport is now also available in wheel format, but this should normally be its last release (unless a pseudo-release is necessary for updating metadata in the future...). The main advantage of updating the backport was to allow all corresponding pages (e.g., on PyPI) to very clearly state that it is not supported anymore.