[Distutils] Re: replacement for tests_require?

Hello, you might want to use the "test" extra: cf https://packaging.python.org/specifications/core-metadata/#provides-extra-multiple-use : "Two feature names test and doc are reserved to mark dependencies that are needed for running automated tests and generating documentation, respectively" --

[Distutils] pip 19.3 release

Hello everyone! On behalf of the PyPA, I am pleased to announce that pip 19.3 has been released. The full release notes are available at https://pip.pypa.io/en/stable/news/ but the main highlights are: - support for `manylinux2014` wheels - slightly faster load time - many bug fixes and lots of

[Distutils] Re: Update PEP 508 to allow version specifiers

On Tue, Jan 29, 2019 at 3:58 PM Donald Stufft wrote: > A version specifier is something like “>=10”. It doesn’t make any sense to > say “I depend explicitly on the version of foo that exists at this URL, and > also that URL has to be >= 10”. You’re already telling us that you depend > on that

[Distutils] Re: Update PEP 508 to allow version specifiers

On Tue, Jan 29, 2019 at 3:22 PM Donald Stufft wrote: > > It still declares a name in the specifier because when doing the > dependency resolution algorithm, it needs to know the name and the version, > and conceptually the name and version of “foo @ > https://example.com/foo.tar.gz” is (“foo”,

[Distutils] Re: Update PEP 508 to allow version specifiers

Thanks Jan for raising this issue. On Tue, Jan 29, 2019 at 10:21 AM Tzu-ping Chung wrote: > I’m wondering, why is it needed to specify both a version and a link? I > assume the version specifier would be redundant when a link is provided > as the source, since the link can only point to one

[Distutils] Re: What are reasonable compatibility tags? (was: Three clarification questions about PEP 425 and PyPy3

Le ven. 31 août 2018 à 9:25 PM, Brett Cannon a écrit : > > OK, so let's look at what we're trying to support. If we have pure Python > code there's very likely going to be a bottom Python version that's > supported and then forward-compatibility is assumed. This is specified > today through

Re: [Distutils] Malicious packages on PyPI

This makes me remember https://hackernoon.com/building-a-botnet-on-pypi-be1ad280b8d6 on a related note. On Thu, Jun 1, 2017 at 7:40 PM, Thomas Kluyver wrote: > On Thu, Jun 1, 2017, at 06:32 PM, Matt Joyce wrote: > > It's basically a test dummy package that reports users

Re: [Distutils] GSoC 2017 - Plan of Action for dependency resolver

Great news ! Your plan seems reasonable. The first stage (RequirementSet refactor) seems to me to be the trickiest. Anyway I'm looking forward for your PRs :) Xavier ___ Distutils-SIG maillist - Distutils-SIG@python.org

Re: [Distutils] distlib and wheel metadata

+1 also. This whole double requirement feels over-complicated for what seems like a rather small usecase: it would be interesting to have a few stats on the number of packages concerned by this pinning (maybe just scan all the last uploaded wheels of each package ?). And if one needs to classify

Re: [Distutils] GSoC 2017 - Working on pip

That's would be a great news :) On Thu, Feb 9, 2017 at 3:15 AM, Pradyun Gedam wrote: > Hello Everyone! > > Ralf Gommers suggested that I put this proposal here on this list, for > feedback and for seeing if anyone would be willing to mentor me. So, here > it is. > > - >

Re: [Distutils] Add data-requires-python attribute to download links in simple repository API

LGTM also :) For the record, I've started a related PR to check Requires-Python in pip at install time: https://github.com/pypa/pip/pull/3846 It should still be useful once PEP 503 is amended, for packages or package indexes that could not expose the Requires-Python information via this new

Re: [Distutils] PEP for specifying build dependencies

I'm not sure that is an issue: if the version is bumped, this won't happen overnight. Why would projects/tools not have the time to update and support semantic-version 1 and 2 ? On Thu, May 12, 2016 at 11:07 AM, Nathaniel Smith wrote: > On Thu, May 12, 2016 at 12:01 AM, Nick

Re: [Distutils] PEP for specifying build dependencies

Thanks for your work ! For what it's worth, I also think that: - semantics-version (or maybe pyproject-version ? to mimic the Wheel-Version of the WHEEL file) should be a top level value; - [build-system] requires = ["setuptools", "wheel"] reads nicely and better than [package.build-system]

Re: [Distutils] wheel 0.28.0 released

Hello Nate, I think there is another regression with version 0.27: wheel files are not zipped anymore. Cf https://bitbucket.org/pypa/wheel/issues/155 and https://bitbucket.org/pypa/wheel/pull-requests/62/ for a possible fix. So watch the size of your wheels with latest version :) Regards,

Re: [Distutils] PEP 513: A Platform Tag for Portable Linux Built Distributions Version

Well, the way I read the pep is that manylinux1 is a policy and also the name of a wheel platform tag. The policy has nothing special except the fact that it is the first one. I think everyone agrees that if this successfully enables linux wheels, there is no reason we won't have any other tags,

Re: [Distutils] PEP 513: A Platform Tag for Portable Linux Built Distributions Version

Hello, The site.py solution seems appropriate but I'd be more in favor of a `sys.supported_platform_tags =['manylinux1']` attribute, with an order of preferences to ease the wheel selection when several such tags will be added. Regards, Xavier Le 26 janv. 2016 23:36, "Nathaniel Smith"

Re: [Distutils] cached index url

Hello, python -c "from pip.baseparser import ConfigOptionParser;print(ConfigOptionParser(name='fo').get_config_files())" could help you. Tested on version 7.1.2. Regards, Xavier On Fri, Dec 18, 2015 at 10:09 AM, Carlos Barera wrote: > Hi, > > In the past I

Re: [Distutils] FINAL DRAFT: Dependency specifier PEP

https://www.python.org/dev/peps/pep-0508/ On Wed, Nov 25, 2015 at 9:05 PM, Marcus Smith wrote: > PEP number yet? > > On Sun, Nov 22, 2015 at 4:45 PM, Donald Stufft wrote: > >> Okay. I’ve read over this, implemented enough of it, and I think it’s >> gone

Re: [Distutils] The future of invoking pip

On Fri, Nov 6, 2015 at 4:52 AM, Glyph Lefkowitz wrote: > > Rather than trying to figure out what the "right" way for users to invoke > `pip´ to begin with is, why not just have Pip start providing more > *information* about potential problems when you invoke it? > > If

Re: [Distutils] PyPi not allowing duplicate filenames

FWIW https://github.com/pypa/pip/pull/3146 exists for the wheel cache. Concerning http cache and https://github.com/ionrock/cachecontrol the main issue is that the cached request is not present in the cache. We only have a "hash -> response" mapping. I plan to make a PR asking to also keep the

Re: [Distutils] it's happened - wheels without sdists (flit)

Fair enough, I didn't think of compiled wheels :) And having a clean way to run tests for the provided wheel is indeed an other good point. On Mon, Mar 30, 2015 at 5:04 PM, Donald Stufft don...@stufft.io wrote: On Mar 30, 2015, at 10:58 AM, Xavier Fernandez xav.fernan...@gmail.com wrote

Re: [Distutils] it's happened - wheels without sdists (flit)

Wheels without sdists are likely a generally bad idea, downstream redistributors are not going to like them. Why do you think that ? Wheels seem way simpler/saner than all the possible things setup.py can do. ___ Distutils-SIG maillist -

Re: [Distutils] it's happened - wheels without sdists (flit)

I think the point was not to say that documentation is useless (and there is some: http://flit.readthedocs.org/en/latest/ ) but that the code/implementation is much simpler than the combination of distutils/setuptools/bdist_wheel. On Mon, Mar 30, 2015 at 5:26 PM, Ian Cordasco

Re: [Distutils] Closing the Delete File + Re-upload File Loophole.

Not sure if it fits your bill (or if it works, since I did not know how testpypi) but you can put something like that in your .pypirc: [distutils] index-servers = pypi testpypi [pypi] username:public_pypi_login_if_needed password:public_pypi_password_if_needed [testpypi]