The proposed workflow is familiar and common in conda. I’m ok with it.
I think there are two missing workflows:
- Simple Scripts
- Publishing
Simple Scripts
Writing simple .py scripts is a common workflow. @pf_moore once posted about this where sometimes you have scripts lying around in a scratch folder. However, the moment you add a third-party tool, the complexity spikes as you now think about dependency management, virtual environments and even making full packages. Can posy help alleviate this overhead? I’d suggest some manner of standardizing third-party dependencies in simple scripts. Example: hatch appears to have a solution to this problem.
Publishing
Publishing packages is a common intermediate workflow. I believe posy is staying clear from the “publish to PyPI” features seen in tools like poetry and flit. However, it may be worth considering standardizing a common UI that integrates with publishing backends based on existing standards. Example: > posy publish could be a common command that flit/poetry/etc publishing tools hook into. Additional args can be passed to the backend tool (in a similar manner to how pipx can pass extra args to the underlying pip backend).
I think including these two workflows could broaden the spectrum of users posy can reach.