GeezerVison is showing github.com — Any chance of releasing wheel packages? · Issue #511 · gitpython-developers/GitPython
Any chance of releasing wheel packages? #511DescriptionPyPI lets you go back and upload new wheels for old packages. Activityankostis commented on Oct 2, 2016 @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 commented on 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 commented on 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.
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 commented on Oct 11, 2016 Byron commented on 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 commented on Oct 16, 2016 Byron commented on Oct 16, 2016 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 commented on Oct 16, 2016 ContributorAuthor More actions Byron commented on 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 commented on Oct 16, 2016 ContributorAuthor More actions Byron commented on 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 ? ankostis commented on Oct 16, 2016
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 commented on Oct 19, 2016 @Byron can we now stop using submodules for smmap & gitdb, and rely on regular import machinery? Byron commented on 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 commented on Oct 25, 2016 ContributorAuthor More actions 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 commented on 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 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 commented on 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 commented on 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 commented on Dec 8, 2016
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 commented on 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.
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 commented on 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 .
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions
|
