Repository navigation
Any chance of releasing wheel packages? #511
Description
Activity
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 :(.
@Byron Have you managed to reset your password?
https://pypi.python.org/pypi?%3Aaction=forgotten_password_form@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 ?gitdb2andsnmap2?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.You should try reaching out again maybe got to the PyPA?
On 16 Oct 2016 10:18 am, "Kostis Anagnostopoulos" notifications@github.com
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
.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.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://cloud.githubusercontent.com/assets/63622/19416203/f0e41b5e-938a-11e6-8a73-f0ced5d930ce.pngGenerally 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
.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
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.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 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
.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__#L16override syspath on runtime, cancelling any
other solution.After having fighted with pip, the monorepo does not seem such a bad idea.
Actually rolling smmap into the gitdb might make sense.@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.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 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
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?
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 .
PyPI lets you go back and upload new wheels for old packages.