Other `pipx list` output formats

How would this feature be useful?

Hopefully this will synthesize (and possibly supersede) Issues #390 and #109. It addresses the reason for PRs #572 and #392.

This Issue is to track exactly what users are looking for with different pipx list output formats.

“Import / Export” set of pipx packages case

In #109, it appears that one primary motivator is the ability to export a file that specifies a set of pipx-installable packages that pipx can then install (possibly on another machine) in the future.

How many users desire this or would find it useful?

It would probably best be done by making a file in json format.

Within this there are some further points for those desiring this functionality:

Do people consider it desired (or necessary?) to freeze all versions of all dependencies for this to be useful? If so then this might be very difficult, based on my investigation creating test code for this.

Simply re-creating a pipx environment, and pinning the version of the main package and any injected packages, and any pipx options is very doable. I have a branch of doing this basically working. In this case, the output would be equivalent to what you would end up with on one machine executing pipx reinstall-all. You can be sure the main package and any injected packages will stay with their specified versions, but you cannot be sure that the versions of any dependencies that still satisfy all package requirements will be the same.

Archive / Documentation case

In #390 it appears that one motivation is simply a concise version of pipx list for “keeping track” or for archival or documentation purposes.

How many users desire this or would find it useful?

Is this type of list output (that is merely more concise) still desired if the “Import / Export” case is available?

What are the goals of this format? What are the use cases specifically? How would one know if the output of this was “successful”?

I must confess that I need this one explained to me, it doesn’t naturally occur to me what is desired. If all that’s needed is documentation of what is currently installed, then the current pipx list seems to cover that. If what is desired is a structured output that would allow one to recreate a pipx environment, then the “Import / Export” json scenario seems to satisfy the need.

@comkieffer @gvoysey @sanketdg @zachvalenta

Describe the solution you’d like

Describe alternatives you’ve considered

[itsayellow]

The json I’m producing right now is pretty-printed. So editing a particular path by hand is actually quite reasonable.

Also, I don’t think I’m eager to have this format be created by hand from scratch, like a config file. I’d like to keep it pipx-generated so that we don’t have to support human quirks that might pop up when we parse it.

[ashwinvis]

I think it is best if this would be combined with an option like pipx reinstall-all --file pipx_packages.toml so that we do not rely on platform dependent shell commands to reinstall pipx packages…

Some pros and cons of different options

	pros	cons
list	human friendly	non-standardised, can break with whitespace changes, cannot represent hierarchial data
json	portable, machine-readable, in standard library	verbose, not human friendly
toml	machine-readable, support for basic types, allows comments, human friendly	new
yaml	machine-readable, support for basic types, allows comments, human friendly	can break with whitespace changes, has known security vulnerablities