question: Why some not that neccesary commands are not separate packages?

[o-murphy]

I'm asking why things like telnet or git aren't separate python packages hosted on pip. From a maintenance perspective it would be nice to separate some things into side-party packages (with pythonista support) This could be a package with appropriate names like git-stash or telnet-pythonista, like bleak-pythonista or like adafruit do it for micropython adafruit-circuitpython-asyncio

If we will support of https://github.com/ywangd/stash/issues/532, this will allow us to implement the logic described above, while the installed packages can have normal short entry point names (git-stash -> git) or same short import names as their big cpython brothers

---

It should look like:

Installation:

pip install git-stash

Run from stash by normal entry point in Documents/bin

$ git

Import by normal name

from git import *

[o-murphy]

This approach also allows individual maintaining for 'heavy' commands

[o-murphy]

I understand that stash provided its own built-in mechanisms for installing some dependencies (like wget, requests, stash(pip install ...), and others), but when we have support for regular pip, this is no longer necessary and can be simplified thanks to an existing and proven tool, i.e. several tools can be replaced by one, which is the standard for Python.

[o-murphy]

Btw. The base small utils like cp, mv, source etc, can be bundled to some python package like busybox-stash

[bennr01]

So, there are actually a couple of reasons.

First, pip relies on certain other commands to install a package. Those will always need to be included for pip to work, otherwise we wouldn't be able to install them.

Secondly, the whole pip-based install is relatively new. Well, it's a couple of years old, but in terms of the amount of commits since it's been introduced is rather new. So most of these commands predate that install. Also, I don't think StaSh can actually be installed via pip. When I (at least I think it was me, it's been a long time) made StaSh a package to allow an install via setup/pip, I've never published the package on PyPI and I don't think anyone else did. So we'd have to first publish StaSh itself as a package before it would make sense to publish the remaining commands. Also, please note that StaSh isn't really installed via pip/setup/pyproject.toml - that's something that exists for developement purposes on PC, but I am really unsure if anyone ever actually used it.

Third, it's a lot of effort for no real benefit. Most commands are rarely changed, if at all. Organizing all repositories, keeping track of the changes and publishing new releases every now and then is a lot of work. At the apex of StaSh developement we got a PR like once or twice a month, sometimes a couple small at once. Pressing the merge button is way less effort than keeping track of all the repositories and publishing the changes to PyPI.

Fouth, a couple of commands are really StaSh specific or useless without StaSh.

There are more reasons, but I think this should illustrate why there's little benefit in doing this. The idea would be great for a large-scale project with a lot of contributors, but StaSh is, while perhaps the largest project in the pythonista ecosystem, ultimately still a small, perhaps medium project and does not require any approach for large-scale developement.

[o-murphy]

Secondly, the whole pip-based install is relatively new. Well, it's a couple of years old, but in terms of the amount of commits since it's been introduced is rather new. So most of these commands predate that install. Also, I don't think StaSh can actually be installed via pip. When I (at least I think it was me, it's been a long time) made StaSh a package to allow an install via setup/pip, I've never published the package on PyPI and I don't think anyone else did. So we'd have to first publish StaSh itself as a package before it would make sense to publish the remaining commands. Also, please note that StaSh isn't really installed via pip/setup/pyproject.toml - that's something that exists for developement purposes on PC, but I am really unsure if anyone ever actually used it.

Thanks great for clarification

I don't suggest breaking the project into a bunch of small ones, I just want to extend the capabilities of stash with the least effort, entry point support is such a feature. It's quite easy to do. And this will be done primarily to support existing third-party python libraries.

I don't suggest using this feature to rewrite working commands

I also plan to clean up the stash code where possible, so that it is more modular and doesn't break when a single dependency changes.

Bellow is my arguments to your comment

1. common pip installation already included to #524, it was borrowed from the pipTerminal project, it uses official https://bootstrap.pypa.io and can be installed even without stash

2. The original stash can be installed with pip from the pypi index, if it is packaged in wheel, believe me, it was not too difficult to replace setup.py with pyproject.toml. I built sdist and wheel locally on my PC. And if I update the setup.py it will be able to do the same as get-stash after installing with pip I think I'll will take it after #524, if nobody mind, I didn't remove setup.py completely for that reason.

3. I agree about commands that are updated infrequently and are not heavy. However, there are also those that are havy, not needed by everyone, or are no longer compatible with stash, tracking their dependencies and updating them is much harder, especially if there are third-party dependencies that do not rely on pip, such as git, gh (use dulwich via wget), crypt (not supported cause pycrypto deprecated and pycryptodome is not supported), etc - these are the commands/modules that can be side-party with it's own deps.

   I've done the bare minimum to make stash to work with py3.13, updated most commands and internal modules, but some modules are so tightly coupled that changing one dependency in an internal module is guaranteed to break a number of others (like DropboxFSI). Some code still need to be fixed and refactored.

4. This commands should not be separated, I understand it. As I emphasized above, this can be partially implemented for specific modules.

[o-murphy]

@bennr01 Maybe convert it to discussion