Any chance of releasing wheel packages?

[graingert]

PyPI lets you go back and upload new wheels for old packages.

[ankostis]

@Byron you may try twine to see if PyPi will let you do something like this:

python setup bdist_wheel
twine register dist/GitPython-2.0.-py2.py3-none-any.whl  # Be  explicit here, globbing dist/* would fail.
twine upload dist/*.whl    # In order to send only the wheels.

[Byron]

That actually worked ! Even though I am not sure if that was a good idea ... should probably publish latest versions of smmap/gitdb too. The good thing is that it's so much easier now thanks to twine ... so far I had to do it all manually and deal with that dated and slow pypi website.

[Byron]

Looks like for smmap (and probably neither for gitdb, which had other errors) it doesn't work as my 'old' user still owns said packages.

twine upload dist/smmap-0.9.0-py2.py3-none-any.whl
Uploading distributions to https://upload.pypi.org/legacy/
Enter your username: ByronBates
Enter your password:
Uploading smmap-0.9.0-py2.py3-none-any.whl
[================================] 35714/35714 - 00:00:02
HTTPError: 403 Client Error: You are not allowed to upload to 'smmap'. for url: https://upload.pypi.org/legacy/

I really wonder how I can ever re-release these :(.

[ankostis]

@Byron Have you managed to reset your password?
https://pypi.python.org/pypi?%3Aaction=forgotten_password_form

[Byron]

@ankostis Thanks for the hint. However, the previous account was not 'real', as it was just a handle to my google id. However, google shut down that system at some point, which made all of these accounts simply unusable, even though they do still own the packages they owned. I tried reaching out to support via e-mail, but never got a reply. I believe the only way to re-release gitdb/smmap is to release them under a different name.
What do you think about that ?

[ankostis]

gitdb2and snmap2?

[Byron]

Yes, let's do it ! snmap2 would be smmap2 though.
Would you like to set up the new names and publish these packages under your name ? In case you are OK with it, all I would ask is to add me as a maintainer or co-owner so we have redundancy.
Once I know your pypi account, I could also add you as maintainer to GitPython, allowing you to make releases yourself.

[graingert]

You should try reaching out again maybe got to the PyPA?

On 16 Oct 2016 10:18 am, "Kostis Anagnostopoulos" [email protected]
wrote:

gitdb2and snmap2?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#511 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAZQTMsuaQwiUZWO84wBr81v-Y10-eoTks5q0d3ngaJpZM4J28uV
.

[Byron]

I am not sure if they are still in existence. Their site claims boasts some copyright information from 2014.

Generally I would rather not try to talk to anyone there again, and just workaround the issue myself. Thus a namechange is so much preferred over sending e-mails.
I will be at the computer today till about 3pm, so it might be entirely possible to set everything up today.

[graingert]

PyPA are definitely still going

On 16 Oct 2016 10:28 am, "Sebastian Thiel" [email protected] wrote:

I am not sure if they are still in existence. Their site
https://www.pypa.io/en/latest/ claims boasts some copyright information
from 2014.
[image: screen shot 2016-10-16 at 10 24 56]
https://cloud.githubusercontent.com/assets/63622/19416203/f0e41b5e-938a-11e6-8a73-f0ced5d930ce.png

Generally I would rather not try to talk to anyone there again, and just
workaround the issue myself. Thus a namechange is so much preferred over
sending e-mails.
I will be at the computer today till about 3pm, so it might be entirely
possible to set everything up today.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#511 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAZQTKRa3I1NzNiFdq6Nxnmbuu4oypA2ks5q0eAqgaJpZM4J28uV
.

[Byron]

I think I might just have managed to release GitPython v2.0.9 with all its dependencies, including itself, as wheels. Thanks to the power of twine, and the work of many contributors, this was easier than expected.
Thanks to all :) !

@graingert Can you verify this is actually correctly working, and close this issue if that's the case ?

[ankostis]

I cannot see it in PyPi: https://pypi.org/search/?q=gitpython
Unless you were talking about github-releases: https://github.com/gitpython-developers/GitPython/releases/tag/2.0.9

[Byron]

Maybe the search 'index' is out of date ? It's definitely there, even though as a wheel only.

[graingert]

You should upload the source package as well as the wheel

On 16 Oct 2016 2:18 pm, "Sebastian Thiel" [email protected] wrote:

Maybe the search 'index' is out of date ? It's definitely there
https://pypi.python.org/pypi?:action=display&name=GitPython&version=2.0.9,
even though as a wheel only.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#511 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAZQTKN63j2y2T_8oXw7GjapeW6M7oRgks5q0hYwgaJpZM4J28uV
.

[Byron]

@graingert Thanks, it's done ! Will try to remember that in future. Also http://pythonwheels.com/ already noticed that GitPython is now available as wheel, and I believe we can close this one.

[ankostis]

Would you like to set up the new names and publish these packages under your name ? In case you are OK with it, all I would ask is to add me as a maintainer or co-owner so we have redundancy.

I would prefer not to become responsible for the releases, since I'm not experienced in the git-internals - I would keep on overviewing the project for Windows issue.

[ankostis]

@Byron can we now stop using submodules for smmap & gitdb, and rely on regular import machinery?

[Byron]

@ankostis I also believe it would be better to not use submodules on the CI and instead use the normal dependency installation mechanism. Do you know how that would work ? Does one pass in the requirement files to pip and that is it ?
Despite that change, I would be fine leaving the submodules in place, as it would make it easier for contributors to get started (I guess - at least that is how I am using them). However, if you don't agree, I would be fine dropping them for good if there are truly in the way.

[graingert]

Maybe just use a monorepo of packages and create a script to automate
deployments and version changes?

On 22 Oct 2016 10:26, "Sebastian Thiel" [email protected] wrote:

@ankostis https://github.com/ankostis I also believe it would be better
to not use submodules on the CI and instead use the normal dependency
installation mechanism. Do you know how that would work ? Does one pass in
the requirement files to pip and that is it ?
Despite that change, I would be fine leaving the submodules in place, as
it would make it easier for contributors to get started (I guess - at least
that is how I am using them). However, if you don't agree, I would be fine
dropping them for good if there are truly in the way.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#511 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAZQTMfP7QzcsvljCcAvFEdYCk1VJHhKks5q2dbggaJpZM4J28uV
.

[ankostis]

I'm using LiClipse, which allows for setting dependencies between open
projects, so you can program in all of them simultaneously. I expect the
same can happen also for PyCharm. As a last, but robust resort, (for
vim, emacs)you may install gitbb and smmap in "develop" mode with
pip install -e <sub-project-dir>, so that your Python will always have
the latest version of these projects in syspath.

The problem is that the submodule code in gitpython:git.__init__#L22
andgitdb:gitdb.__init__#L16 override syspath on runtime, cancelling any
other solution.

[ankostis]

After having fighted with pip, the monorepo does not seem such a bad idea.
Actually rolling smmap into the gitdb might make sense.

[Byron]

@ankostis I could easily do that! This would also mean that the special handling to add the code into the path will always be on.
If you don't see an issue with that, I will do it right way.

Maybe you meant to only merge smmap into gitdb, and while still keeping it in a separate repository.
In any case, a new version of all affected packages would have to be released, in order to be self-contained.

[ankostis]

Maybe you meant to only merge smmap into gitdb,

Yes, when i said that, I was refering to merge only smmap into gitdb.
But if possible, please don't hurry, I will answer to your next points.

[ankostis]

@ankostis I could easily do that! This would also mean that the special handling to add the code into the path will always be on.

The special-handling can go away eitherway. For instance, when rolling both projects into the same code-based. you can either put smmap as a top-level directory and this can be appended into the distribution's packages lke this: setup.py:setup(packages=['gitdb', 'smmap']), so practically gitdb package would then distribute both projects. Another alternative is to vendorize smmap, and move it into a nested dir i.e. gitdb/smmap.

But isn't it possible to make the new release with the current situation, and defer this decision for the next major-version bump?

[Byron]

Of course, let's defer the decision then. Let's record here that there is nothing holding us back to change the repository configuration, or even project configuration, to make maintaining the project easier.

Ideally, interested parties can create a new issue for that, so we can let this one rest in piece :D .