Thank you for the ability to do `pip install git+https://...`
Dunno how old/new this feature is, or what people did before it existed, but I just wanted to thank the people who thought of and built the ability to do installs from git+https.
It lets me offer the following to my users when they want the “bleeding edge” https://github.com/nchammas/flintrock#development-version version of my project:
pip install git+https://github.com/nchammas/flintrock
I also use this capability to install and test contributors’ branches when they open PRs against my project. For example:
pip install git+https://github.com/contributor/flintrock@branch
It’s a great feature and makes my work a bit easier. Thank you for building it.
I’m still waiting for when I can give the PyPA some money https://github.com/pypa/warehouse/issues/856 for all the good and sorely needed work that y’all do…
Anyway, keep it up.
Nick
You could always point pip to the automatically generated zip (https://github.com/nchammas/flintrock/archive/master.zip). That way you won't have to wait for git to pointlessly download your entire version history when you just want to install something.
28.03.2016, 04:11, Nicholas Chammas kirjoitti:
Dunno how old/new this feature is, or what people did before it existed, but I just wanted to thank the people who thought of and built the ability to do installs from |git+https|.
It lets me offer the following to my users when they want the “bleeding edge” https://github.com/nchammas/flintrock#development-version version of my project:
|pip install git+https://github.com/nchammas/flintrock |
I also use this capability to install and test contributors’ branches when they open PRs against my project. For example:
|pip install git+https://github.com/contributor/flintrock@branch |
It’s a great feature and makes my work a bit easier. Thank you for building it.
I’m still waiting for when I can give the PyPA some money https://github.com/pypa/warehouse/issues/856 for all the good and sorely needed work that y’all do…
Anyway, keep it up.
Nick
Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
On 28 March 2016 at 22:54, Alex Grönholm alex.gronholm@nextday.fi wrote:
You could always point pip to the automatically generated zip (https://github.com/nchammas/flintrock/archive/master.zip). That way you won't have to wait for git to pointlessly download your entire version history when you just want to install something.
I'd assume pip is doing shallow clones when installing from version control, and if that currently isn't the case due to lack of time for implementation and testing, it should be a relatively straightforward PR for someone to submit as a performance optimisation.
It's also the case that the automatically generated zip archives are a GitHub specific feature rather than a general property of version control systems, so at least some folks are going to avoid depending on that service specific feature and instead favour the host-independent approach of using the relevant version control protocol.
Regards, Nick.
P.S. More generally: is a thread where someone is saying "Thanks for this feature!" *really* the best place to be telling them "you shouldn't be using that feature"? It's rare enough for maintainers of any open source project to hear a heartfelt "thank you" that it's at least worth considering taking other replies off list :)
I'm sorry if I offended anyone. I was just trying to point out that in the case of Github (or any other service that provides automated tarball generation) it's better to install from those rather than using the VCS integration plugins. Oh, and for the record, I just tested -- it does a deep clone at this time, which would be responsible for the slowness compared to installing from a tarball.
01.04.2016, 17:03, Nick Coghlan kirjoitti:
On 28 March 2016 at 22:54, Alex Grönholm alex.gronholm@nextday.fi wrote:
You could always point pip to the automatically generated zip (https://github.com/nchammas/flintrock/archive/master.zip). That way you won't have to wait for git to pointlessly download your entire version history when you just want to install something.
I'd assume pip is doing shallow clones when installing from version control, and if that currently isn't the case due to lack of time for implementation and testing, it should be a relatively straightforward PR for someone to submit as a performance optimisation.
It's also the case that the automatically generated zip archives are a GitHub specific feature rather than a general property of version control systems, so at least some folks are going to avoid depending on that service specific feature and instead favour the host-independent approach of using the relevant version control protocol.
Regards, Nick.
P.S. More generally: is a thread where someone is saying "Thanks for this feature!" *really* the best place to be telling them "you shouldn't be using that feature"? It's rare enough for maintainers of any open source project to hear a heartfelt "thank you" that it's at least worth considering taking other replies off list :)
On 2016-04-01 17:16:15 +0300 (+0300), Alex Grönholm wrote:
I'm sorry if I offended anyone. I was just trying to point out that in the case of Github (or any other service that provides automated tarball generation) it's better to install from those rather than using the VCS integration plugins. Oh, and for the record, I just tested -- it does a deep clone at this time, which would be responsible for the slowness compared to installing from a tarball.
Whether this can work depends entirely on the project being installed. Some don't check package metadata into their repos in a form consumable by pip, and require an additional sdist build step which may need information from the VCS itself or manually provided during that step.
A prime example of this is projects using PBR, which will want access to Git tag and commit details to determine the package version. With a local clone of the project's Git repository (not just a tarball/zip snapshot of its content) you can build a pip-supported sdist, but otherwise you may need to manually determine and set version information in the calling environment or by editing to be able to then generate a usable sdist from the raw source tree.
participants (4)
-
Alex Grönholm -
Jeremy Stanley -
Nicholas Chammas -
Nick Coghlan