Add gobal --skip-maintenance option (i.e., allow pipx to work without network access)

[christian-krieg]

How would this feature be useful?

I have a similar problem as discussed in #1081 when attempting to pipx install a wheel on a machine without Internet access. All dependencies are available as wheels in a deps directory, and I pass --no-index and --find-links=deps options with --pip-args. Still, it is not possible to install the package, because pipx is trying to connect to the Internet without success, resulting in a connection timeout.

Having a global --skip-maintenance option would allow one to use pipx on machines without access to the Internet.

Describe the solution you'd like

I ported the fix provided in #1163 to the install command, so when calling pipx install --skip-maintenance, installing a local wheel works just fine.

In order to avoid code duplication, I suggest to make --skip-maintenance a global option to pipx, instead of implementing this feature for every single command it might be useful for, such that pipx --skip-maintenance install would be available.

Describe alternatives you've considered

The only alternative I have considered and tested so far is using pip instead of pipx (which successfully installs the wheel and dependencies, but without the isolation that comes with pipx).

[chrysle]

Thanks for opening this issue!

It is curently being worked on deprecating the --skip-maintenance flag in #1256 in favour of a less involved solution for the users. However that would not be compliant with your use case (which I think is valid), as the install command will still reach out to the internet. You are welcome to opine on the linked pull request. I think it shouldn't be too hard to enable users manually disabling the newly created functionality via the command line.

[christian-krieg]

Hi @chrysle, thank you very much for the pointer! As far as I understand, #1256 seeks to disable maintenance tasks for contexts in which a user wouldn't expect such tasks.

While this may work perfectly well for many users and probably almost all use cases, I am wondering whether it may be favorable to let the user decide using pipx without network access (or to declare some network timeout value).

So, having some global --offline flag to explicitly declare offline usage would be awesome. Of course, I understand that a minimal set of command line options is desirable from a dev's point of view. However, it seems that there is no option yet to specify network usage, so an --offline flag would be orthogonal to existing options.

[Gitznik]

So, having some global --offline flag to explicitly declare offline usage would be awesome. Of course, I understand that a minimal set of command line options is desirable from a dev's point of view. However, it seems that there is no option yet to specify network usage, so an --offline flag would be orthogonal to existing options.

While the --skip-maintenance flag is quite easy to implement as it only impacts a very defined part of the application, a global --ofline flag IMO would be quite tricky to implement and ensure the behavior of. A lot (most) of our network calls are via calling pip in a subcommand. We would have to parse all those commands and specify which pip commands call out to the internet and which ones don't.

E.g. during --ofline == True, we'd have to allow installations of local packages, but forbid installations from remote servers, while still allowing installations from repositories running on localhost, ... all by parsing and defining the rules for the provided installation location.

From my perspective the maintenance tasks are the only tasks that reach out to the internet in a way that is not intuitive to the user. For anything else (the user trying to install a local vs a remote package), the user should be aware whether that will require a network call or not, and it should not be the responsibility of pipx to handle it.

Aside from the shared packages maintenance, do we have more network calls that may not be intuitive?

[christian-krieg]

@Gitznik, thank you very much for taking your time to elaborate the implications of an --offline switch. I agree that having such a switch may not be reasonable. I will change the name of the flag in the title back to --skip-maintenance.

If implemented, it may be helpful to document something like skip maintenance tasks (which may require a network connection) or something similar in the option's help text. I suspect that the motivation for most users potentially using this flag may be a desire to avoid reaching out to the network. This is why I changed the flag's name to --offline.

[Gitznik]

If implemented, it may be helpful to document something like skip maintenance tasks (which may require a network connection) or something similar in the option's help text. I suspect that the motivation for most users potentially using this flag may be a desire to avoid reaching out to the network. This is why I changed the flag's name to --offline.

I'm all for making the behavior of that flag clearer to the user 👍

IMO a PR for making --skip-maintenance a global flag and improving the docs around it would be welcome :)

[chrysle]

IMO a PR for making --skip-maintenance a global flag and improving the docs around it would be welcome :)

I agree, but let's hold this until #1256 is merged. Then we could extend the global args and pass them in the newly created function.

[christian-krieg]

I would be happy to work on such a PR and subscribed to #1256 to monitor its progress.

[Arpafaucon]

Hi @christian-krieg , just letting you know that #1256 was merged :)