plumbing commands and a simple database

[RonnyPfannschmidt]

in order to give people more freedoms (like installing a set of packages and scripts into a single pipsi environment lower level commands should be exposed

• add a pipsi owned json file that tracks the environments and their requested packages/scripts/script packages
• command to create a named empty environment
• command to destroy a environment and its belonging scripts
• command to install a package into a environment, supporting all pip arguments ( pip ?)
• command install all or specific scripts of a package from a environment to the bin folder
• command to recreate a environment and its packages in the easy case (must refuse in the "hard case")
• command to try and recreate a environment even in the hard case

the implementation logic of pipsi install would boil down to the following

pipsi create ${PACKAGENAME} && $(pipsi path  ${PACKAGENAME})/bin/pip install ${PACKAGENAME}
if !pipsi link_scripts ${PACKAGENAME} ${PACKAGENAME}
then
  echo ' ${PACKAGENAME} has no scripts!'
  pipsi destroy ${PACKAGENAME}
fi

what should be tracked in the "database" is still subject to planing and discssion

at least the scripts installed and the packages requested should be tracked somehow
but given the flexibility of pip

[rocktavious]

+100 for this - I'm using pipsi in all my docker containers to give them isolated environment commandline tools, and there are a few (IE awscli) which doesn't seem to be detected by pipsi. Let me know if i can help move this forward. (Just found out about pipsi 1 month ago and i'm loving it!!!)

[RonnyPfannschmidt]

there is way you can help

1. start implementing/proposing items from the checklist above and
2. check out projects with bad packaging (like awscli) and help them to get better at it

[ryneeverett]

I see where a lot of the currently requested features would be better implemented with a database tracking state, but what is the use case for the plumbing commands (create, destroy)? And how would destroy differ from uninstall?

[RonnyPfannschmidt]

Create and destroy are about venv, not packages
This is about more abstraction levels

[ryneeverett]

Currently uninstall just deletes the venv so I'm not sure how destroy would differ. I also question the sensibility of adding and exposing abstraction levels with no use cases.

[RonnyPfannschmidt]

@ryneeverett well, if you want to do stuff like an environment with a package that has plugins, currently that cant work, if yout want to instal lscripts of 2 different packages, that wont work - and that list goes on

[ryneeverett]

So uninstall would be changed to just remove a specific package from an environment?

[RonnyPfannschmidt]

no, that would break the normal workflow for non-plumbing commands

[igalic]

command to recreate a environment and its packages in the easy case (must refuse in the "hard case")

this would a nice-to-have, as it would allow for easily updating a package's python version for instance.

[RonnyPfannschmidt]

closing to get if off my plate on github