You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@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.
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.
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 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 ?
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.
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.
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.
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 ?
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 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.
@ankostishttps://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.
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 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 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?
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 .
Activity
ankostis commentedon Oct 2, 2016
@Byron you may try twine to see if PyPi will let you do something like this:
Byron commentedon Oct 9, 2016
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 commentedon Oct 9, 2016
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.
I really wonder how I can ever re-release these :(.
ankostis commentedon Oct 11, 2016
@Byron Have you managed to reset your password?
https://pypi.python.org/pypi?%3Aaction=forgotten_password_form
Byron commentedon Oct 16, 2016
@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 commentedon Oct 16, 2016
gitdb2andsnmap2?Byron commentedon Oct 16, 2016
Yes, let's do it !
snmap2would besmmap2though.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 commentedon Oct 16, 2016
You should try reaching out again maybe got to the PyPA?
On 16 Oct 2016 10:18 am, "Kostis Anagnostopoulos" notifications@github.com
wrote:
Byron commentedon Oct 16, 2016
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 commentedon Oct 16, 2016
PyPA are definitely still going
On 16 Oct 2016 10:28 am, "Sebastian Thiel" notifications@github.com 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://github.com/proxy/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 commentedon Oct 16, 2016
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 ?
5 remaining items
ankostis commentedon Oct 16, 2016
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 commentedon Oct 19, 2016
@Byron can we now stop using submodules for smmap & gitdb, and rely on regular import machinery?
Byron commentedon Oct 22, 2016
@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 commentedon Oct 25, 2016
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" notifications@github.com wrote:
ankostis commentedon Oct 25, 2016
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 havethe latest version of these projects in syspath.
The problem is that the submodule code in
gitpython:git.__init__#L22and
gitdb:gitdb.__init__#L16override syspath on runtime, cancelling anyother solution.
ankostis commentedon Oct 27, 2016
After having fighted with pip, the monorepo does not seem such a bad idea.
Actually rolling smmap into the gitdb might make sense.
Byron commentedon Dec 8, 2016
@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 commentedon Dec 8, 2016
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 commentedon Dec 8, 2016
The special-handling can go away eitherway. For instance, when rolling both projects into the same code-based. you can either put
smmapas 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 commentedon Dec 8, 2016
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 .