Release New Version to PyPi

[rxm7706]

Hello,

Do you have any plans to release a new version to PyPi
https://pypi.org/project/smmap/#history
Both the PyPi version & Conda-forge version are quite outdated - Version 5.0 October 2021.

Thank You and Regards,

[Byron]

Thanks for the hint. There are no improvements, just different declarations of compatible python versions.

Now that I think about it, it would certainly be better to keep stating compatibility to EOL versions of python as the library is indeed compatible to a lot of these. Oh well, something to fix another day.

https://pypi.org/project/smmap/6.0.0/

@EliahKagan I remember mentioning that it's probably better, i.e. more compatible, to declare all python versions that a library is actually compatible with, instead of removing EOL python versions out of principle. Now that I have released another major release of smmap that removed such EOL python support I realize my mistake. However, this also means that when adjusting the supported versions in setup.py (or equivalent), one will have to consider gitdb as well, and follow through to this project, smmap, that gitdb depends on. I don't think it's much effort or a big deal, it's just something to remember. And now that I write this, I realize that maybe it's nothing one have to take care of as pip will automatically choose the correct version of gitdb and smmap anyway as long as the version range is sufficient.

[EliahKagan]

pip will choose a compatible version, taking the old smmap on 3.7, so nothing has to be done in GitPython or gitdb to keep 3.7 support in those projects. (Edit: But something does have to be done to get them to use smmap 6 at all; see gitpython-developers/gitdb#95.) However, I do recommend fixing this, which can be done simply by widening the range back down to a lower bound of 3.7 and releasing a bugfix version 6.0.1.

I've opened #52 for this. It adds back 3.7 support and is analogous to gitpython-developers/gitdb#94.

One reason I consider it worthwhile to fix this is to that other projects that support the range 3.7-3.12 can pin a single specific version that will work and is documented to work.

However, if the only thing that had to be done to support newer versions was adding classifiers for them, and they actually worked before (since classifiers aren't needed to permit installation), and nothing else was changed, then either a 6.0.1 could be released or 6.0.0 could be yanked, I suppose.

@Byron This reminds me of something I had been meaning to ask you, which also may help me be more (or less?) confident about edit: actually turns out not to affect my claim in my first paragraph here. In case it impacts any further changes that might be made here sooner than I can investigate it further, I'll just ask here...

How is GitPython using its submodules, exactly? Both before and after the change to installing GitPython for the tests, its dependencies were being installed with pip. So I expect those, both before and now, to take precedence over the submodules. With setup.py explicitly excluding "git.ext.*", running pip install -e . should not have included that in the editable install. So packages installed with pip in the environment should take precedence over the subdirectories found in the local directory. Furthermore, these are traditional packages (i.e., the main kind, including today: the kind that have __init__.py), so no merging is happening: only the first package found is used, and I think that should be the one pip installed.

If the purpose of using submodules was just to allow the dependency to be edited, I think that may not justify their use. pip supports installing any directory, it doesn't have to be ., and it can install it as an editable install with -e. Furthermore, pip supports installing from a remote Git repository, including GitHub, including arbitrary refs (e.g., install a feature branch).

[EliahKagan]

Oh, I see. In git/__init__.py:

__version__ = "git"


# { Initialization
def _init_externals() -> None:
    """Initialize external projects by putting them into the path"""
    if __version__ == "git" and "PYOXIDIZER" not in os.environ:
        sys.path.insert(1, osp.join(osp.dirname(__file__), "ext", "gitdb"))

    try:
        import gitdb
    except ImportError as e:
        raise ImportError("'gitdb' could not be found in your PYTHONPATH") from e
    # END verify import


# } END initialization

Putting it early in PYTHONPATH should force it to be found and take precedence. But this doesn't require that it be installed, in any sense that the version limitation in setup.py gets in the way of. So it is using the files from the submodule, but f1b4d14 shouldn't prevent that.

I wonder if we can stop doing that, though. I think testing GitPython with its actual dependencies like it gets them "in the wild" is valuable, and pip's versatility in letting a package be installed from just about any location (plus: if one prefers, one can build a wheel or sdist, and then install it, all locally) should be sufficient, on the occasions it might be needed, to achieve the goals of having GitPython use submodules... if I understand what those goals were/are.

[Byron]

Thanks for chiming in! I think it makes sense to yank v6.0 and release a 6.0.1 to open the version range. There wouldn't have been the need for a 6.0 in the first place, so I guess I can make it 5.0.1 as well and there is less work for everyone. Here is the new release: https://pypi.org/project/smmap/5.0.1/ .

About submodules

Indeed, submodules are a relic of the past where pip -e didn't exist or I didn't know about it. They are merely to make it possible to edit a package locally. I think complexity would be reduced, along with maybe an additional attack vector, if submodules would be removed. Thanks again for bringing this up!

[EliahKagan]

It turns out the code in git/__init__.py actually doesn't (ever) have the effect it intends and appears to have. I've opened gitpython-developers/GitPython#1717 about this. As described there, I view this as an opportunity to incrementally decrease GitPython's use of its git-submodules.