Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release New Version to PyPi #51

Closed
rxm7706 opened this issue Sep 16, 2023 · 5 comments
Closed

Release New Version to PyPi #51

rxm7706 opened this issue Sep 16, 2023 · 5 comments

Comments

@rxm7706
Copy link

rxm7706 commented Sep 16, 2023

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
Copy link
Member

Byron commented Sep 17, 2023

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.

@Byron Byron closed this as completed Sep 17, 2023
@EliahKagan
Copy link
Contributor

EliahKagan commented Sep 17, 2023

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
Copy link
Contributor

EliahKagan commented Sep 17, 2023

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
Copy link
Member

Byron commented Sep 17, 2023

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
Copy link
Contributor

EliahKagan commented Oct 20, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants