Repository navigation
Release New Version to PyPi #51
Description
Activity
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
smmapthat removed such EOL python support I realize my mistake. However, this also means that when adjusting the supported versions insetup.py(or equivalent), one will have to considergitdbas well, and follow through to this project,smmap, thatgitdbdepends 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 aspipwill automatically choose the correct version ofgitdbandsmmapanyway as long as the version range is sufficient.pipwill choose a compatible version, taking the oldsmmapon 3.7, so nothing has to be done inGitPythonorgitdbto keep 3.7 support in those projects. (Edit: But something does have to be done to get them to usesmmap6 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 aboutedit: 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
GitPythonusing its submodules, exactly? Both before and after the change to installingGitPythonfor the tests, its dependencies were being installed withpip. So I expect those, both before and now, to take precedence over the submodules. Withsetup.pyexplicitly excluding"git.ext.*", runningpip install -e .should not have included that in the editable install. So packages installed withpipin 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 onepipinstalled.If the purpose of using submodules was just to allow the dependency to be edited, I think that may not justify their use.
pipsupports installing any directory, it doesn't have to be., and it can install it as an editable install with-e. Furthermore,pipsupports installing from a remote Git repository, including GitHub, including arbitrary refs (e.g., install a feature branch).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
PYTHONPATHshould force it to be found and take precedence. But this doesn't require that it be installed, in any sense that the version limitation insetup.pygets 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 havingGitPythonuse submodules... if I understand what those goals were/are.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 -edidn'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!Reacted by Eliah KaganIt turns out the code in
git/__init__.pyactually 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.Reacted by Sebastian Thiel
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,