Re: Thoughts on '--force' option for pip install?

2018-04-30 Thread Loren Carvalho
thanks for the suggestion! done https://github.com/pypa/pip/issues/5355

On Monday, April 30, 2018 at 10:48:29 AM UTC-5, p.f.moore wrote:
>
> Maybe the check could simply warn rather than abort the install when 
> used with --target? Actually, --target installs are weird in so many 
> ways, that longer term it might be better to split them out as a 
> completely separate option. But that's probably more than we want to 
> tackle for this question. 
>
> I'd suggest opening this as a feature request on the tracker. 
>
> Paul 
>
> On 30 April 2018 at 16:32, Loren Carvalho  > wrote: 
> > Howdy pypa-dev ! 
> > 
> > I am the maintainer of a (newly open sourced!) project called "shiv". 
> Shiv 
> > is a cli tool to build zipapp-style PYZ files with all direct & 
> transitive 
> > dependencies included. The way we do this is by leveraging `pip install 
> > --target` and then including the resulting site-packages style dir into 
> the 
> > PYZ file (as well as some bootstrapping code). As such, our pyz files do 
> not 
> > provide cross-platform support, which isn't a big concern to our use 
> case 
> > (we have build machines that match each of our target archs), but we 
> have a 
> > PR from some folks who are interested in making the resulting pyz files 
> > portable across platforms (or at least insofar as manylinux wheels are 
> > portable). 
> > 
> > Here's the PR for context: https://github.com/linkedin/shiv/pull/7 
> > 
> > I'd like to continue shelling out to the `install` subcommand because it 
> > works really nicely with our build system 
> > (https://github.com/linkedin/pygradle), but I'd also love to make the 
> tool 
> > more usable from folks who are interested in cross-plat support. 
> > 
> > So, as noted in the PR I linked above, we *can* build pyz's that are 
> > manylinux compatible today, if we first download the wheels (via pip 
> > download) and then rename them to "fake" the pep425tags check during 
> > Wheel.install, here's an example of what I mean: 
> > https://github.com/linkedin/shiv/pull/7#issuecomment-385409844 
> > 
> > So, all this is to say, rather than doing this wheel-renaming hack, 
> would 
> > PyPA/Pip be open to a PR that adds a "--force" option to `pip install`? 
> Or 
> > maybe something more specific like "--skip-pep425-check" or something 
> like 
> > that? Do you anticipate any weirdness or bugs? Perusing the codebase, if 
> > we're just dealing with wheels I can't imagine there'd be anything wacky 
> > happening since there is no additional compilation or anything like 
> that. 
> > 
> > Thanks in advance! 
> > 
> > -- Loren 
> > 
> > 
>


Fwd: [pypi-announce] legacy.pypi.org shut down, please use pypi.org

2018-04-30 Thread Sumana Harihareswara
Roadmap's updated https://wiki.python.org/psf/WarehouseRoadmap . We'd
love your help for the next chapter, the post-legacy-shutdown tasks:
https://github.com/pypa/warehouse/milestone/12


-- 
Sumana Harihareswara
PyPI/Warehouse project manager
Changeset Consulting
https://changeset.nyc


 Forwarded Message 
Subject: [pypi-announce] legacy.pypi.org shut down, please use pypi.org
Date: Mon, 30 Apr 2018 15:25:50 -
From: s...@changeset.nyc
Reply-To: distutils-...@python.org
To: pypi-annou...@python.org

We have sunset the original Python Package Index service, which was
temporarily deployed at https://legacy.pypi.org .


The new PyPI is at https://pypi.org . Browser and API calls to
pypi.python.org will continue to redirect to pypi.org .


If you have been using legacy.pypi.org directly, please start using
pypi.org :
https://warehouse.readthedocs.io/api-reference/integration-guide/#migrating-to-the-new-pypi
If there is a feature that the new codebase does not support, you should
file an issue at https://github.com/pypa/warehouse/issues as soon as
possible.


If you use JFrog Artifactory, please make sure you're running the latest
version. Please see the guidance from JFrog
https://jfrog.com/knowledge-base/why-am-i-not-able-to-connect-to-pypi-python-org/
and full discussion of the issue
https://github.com/pypa/warehouse/issues/3275 .


Maintenance report on the sunsetting:
https://status.python.org/incidents/ptvp1wnn0jmq


Historical context and future plans: https://lwn.net/Articles/751458/


Sincerely,
Sumana Harihareswara on behalf of the PyPI team
___
pypi-announce mailing list
pypi-annou...@python.org
https://mail.python.org/mm3/mailman3/lists/pypi-announce.python.org/


Re: Thoughts on '--force' option for pip install?

2018-04-30 Thread Paul Moore
Maybe the check could simply warn rather than abort the install when
used with --target? Actually, --target installs are weird in so many
ways, that longer term it might be better to split them out as a
completely separate option. But that's probably more than we want to
tackle for this question.

I'd suggest opening this as a feature request on the tracker.

Paul

On 30 April 2018 at 16:32, Loren Carvalho  wrote:
> Howdy pypa-dev !
>
> I am the maintainer of a (newly open sourced!) project called "shiv". Shiv
> is a cli tool to build zipapp-style PYZ files with all direct & transitive
> dependencies included. The way we do this is by leveraging `pip install
> --target` and then including the resulting site-packages style dir into the
> PYZ file (as well as some bootstrapping code). As such, our pyz files do not
> provide cross-platform support, which isn't a big concern to our use case
> (we have build machines that match each of our target archs), but we have a
> PR from some folks who are interested in making the resulting pyz files
> portable across platforms (or at least insofar as manylinux wheels are
> portable).
>
> Here's the PR for context: https://github.com/linkedin/shiv/pull/7
>
> I'd like to continue shelling out to the `install` subcommand because it
> works really nicely with our build system
> (https://github.com/linkedin/pygradle), but I'd also love to make the tool
> more usable from folks who are interested in cross-plat support.
>
> So, as noted in the PR I linked above, we *can* build pyz's that are
> manylinux compatible today, if we first download the wheels (via pip
> download) and then rename them to "fake" the pep425tags check during
> Wheel.install, here's an example of what I mean:
> https://github.com/linkedin/shiv/pull/7#issuecomment-385409844
>
> So, all this is to say, rather than doing this wheel-renaming hack, would
> PyPA/Pip be open to a PR that adds a "--force" option to `pip install`? Or
> maybe something more specific like "--skip-pep425-check" or something like
> that? Do you anticipate any weirdness or bugs? Perusing the codebase, if
> we're just dealing with wheels I can't imagine there'd be anything wacky
> happening since there is no additional compilation or anything like that.
>
> Thanks in advance!
>
> -- Loren
>
>


Thoughts on '--force' option for pip install?

2018-04-30 Thread Loren Carvalho
Howdy pypa-dev !

I am the maintainer of a (newly open sourced!) project called "shiv". Shiv 
is a cli tool to build zipapp-style PYZ files with all direct & transitive 
dependencies included. The way we do this is by leveraging `pip install 
--target` and then including the resulting site-packages style dir into the 
PYZ file (as well as some bootstrapping code). As such, our pyz files do 
not provide cross-platform support, which isn't a big concern to our use 
case (we have build machines that match each of our target archs), but we 
have a PR from some folks who are interested in making the resulting pyz 
files portable across platforms (or at least insofar as manylinux wheels 
are portable). 

Here's the PR for context: https://github.com/linkedin/shiv/pull/7

I'd like to continue shelling out to the `install` subcommand because it 
works really nicely with our build system 
(https://github.com/linkedin/pygradle), but I'd also love to make the tool 
more usable from folks who are interested in cross-plat support. 

So, as noted in the PR I linked above, we *can* build pyz's that are 
manylinux compatible today, if we first download the wheels (via pip 
download) and then rename them to "fake" the pep425tags check during 
Wheel.install, here's an example of what I 
mean: https://github.com/linkedin/shiv/pull/7#issuecomment-385409844

So, all this is to say, rather than doing this wheel-renaming hack, would 
PyPA/Pip be open to a PR that adds a "--force" option to `pip install`? Or 
maybe something more specific like "--skip-pep425-check" or something like 
that? Do you anticipate any weirdness or bugs? Perusing the codebase, if 
we're just dealing with wheels I can't imagine there'd be anything wacky 
happening since there is no additional compilation or anything like that.

Thanks in advance!

-- Loren