[Distutils] Re: Setuptools adopts distutils

Indeed – this is major step forward! On 3.7.2020 18.59, Paul Moore wrote: Awesome! Congratulations on achieving this :-) Paul On Fri, 3 Jul 2020 at 16:26, Jason R. Coombs wrote: I’m pleased to announce the release of Setuptools 48, which adopts the distutils codebase from CPython per

[Distutils] Re: Setuptools use pip over easy_install when installing through setup.py

You should not depend on running setup.py to install dependencies. Use pip instead, always. Pokestar Fan kirjoitti 25.12.2019 klo 6.52: I was running a test program through setup.py, and it threw an error whenever it tried to install a package on a Windows 10 Python 3.8 installation (It

[Distutils] Re: Namespaces and setup.cfg

recent call last): File "", line 1, in ImportError: No module named svg I attached a full log, plus the failing package file. On Sun, Nov 3, 2019 at 7:02 PM Alex Grönholm wrote: I was unable to reproduce the issues you're seeing. Could you give detailed repro instructions? Lenna

[Distutils] Re: Namespaces and setup.cfg

I was unable to reproduce the issues you're seeing. Could you give detailed repro instructions? Lennart Regebro kirjoitti 3.11.2019 klo 17.46: Heya! I recently moved all the setup.py configuration into setup.cfg for Pyroma. That worked very nicely. So I started doing it for my other packages,

[Distutils] Re: failing to build a windows python38 wheel

This was fixed in wheel v0.33.5. Marius Gedminas kirjoitti 30.10.2019 klo 11.58: On Tue, Oct 29, 2019 at 03:09:08PM +, Robin Becker wrote: On 29/10/2019 12:53, Robin Becker wrote: Hi, I am trying to use the technique of pillow to pre-emptively build windows 38 wheel for x_64 and also

[Distutils] Review help: Automatic detection of macOS platform tag

There's a pull request against wheel that I feel out of my depth reviewing: https://github.com/pypa/wheel/pull/314 I'm looking for anyone with experience on macOS binary compatibility to help validate the solution. Help is really appreciated! -- Distutils-SIG mailing list --

[Distutils] Re: travis problem

This is not related to Python packaging per se, but I'll bite. I'm not seeing difficulties but then again I am using the Xenial images in all my projects. Could you try upgrading from Trusty to Xenial in your Travis configuration? Robin Becker kirjoitti 16.9.2019 klo 19.08: Channelling the

[Distutils] Wheel 0.32 released

This release contains the following significant changes: * Wheel signature generation and verification commands have been removed * The wheel installation features have been removed * The documentation has been rewritten to conform to the PyPA guidelines * The ability to add multiple license

[Distutils] Re: disable building wheel for a package

I'm curious: what data does it attempt to install and where? Have you created a ticket for this somewhere? ke, 2018-09-12 kello 15:56 -0400, sashk kirjoitti: > > > > > I agree with Nathaniel - the correct solution is to fix your > > > package > > > so that can be built as a wheel which

Re: [Distutils] Cannot install pyopencl

This mailing list is for packaging development discussion. Questions on how to install packages should be directed to either #pypa or #python on Freenode IRC, or sites like StackOverflow. Tim Graham kirjoitti 16.03.2018 klo 17:12: Hello I wonder if you can help…. I am trying to install

Re: [Distutils] PyPI support for linux_ppc64le

The manylinux1 platform only supports x86-64 and x86-32 (i686) architectures. A quote from PEP 513: Because CentOS 5 is only available for x86_64 and i686 architectures, these are the only architectures currently supported by the manylinux1 policy. If support is to be extended to other

Re: [Distutils] Building a Python package build service for warehouse

I'd be all for it if I wasn't buried under a ton of other things to do. Happy hacking and good luck! Jannis Gebauer kirjoitti 06.02.2018 klo 10:33: Hi! I’m currently working on a package build server. My goal is to produce useful additional meta data for all packages available on PyPi.

Re: [Distutils] PEP 508, environment markers & the possibility of Python 3.10

Hasn't Guido said publicly that 4.0 would be the next version from 3.9 (since he hates double digits)? Nick Coghlan kirjoitti 28.01.2018 klo 07:44: Hi folks, In https://github.com/python/peps/issues/560, a user pointed out that the current definition of python_version in PEP 508 assumes

Re: [Distutils] Installed Extras Metadata

Pradyun Gedam kirjoitti 26.01.2018 klo 17:11: Hello! I hope everyone's had a great start to 2018! :) A few months back, while working on pip, I had noticed an oddity about extras. Installing a package with extras would not store information about the fact that the extras were requested.

Re: [Distutils] PEP 566 - metadata 1.3 changes

+1 from me. While I dislike the fact that "2.0" was put to use prematurely, using "2.1" is still less confusing than going from 2.0 to 1.3. Nick Coghlan kirjoitti 20.01.2018 klo 05:07: On 19 January 2018 at 00:14, Joni Orponen wrote: On Thu, Jan 18, 2018 at 5:58 AM,

Re: [Distutils] PEP 566 - metadata 1.3 changes

Whichever we choose, the metadata version should match the PEP version, which it currently does not. Nathaniel Smith kirjoitti 16.01.2018 klo 18:58: On Jan 12, 2018 8:00 AM, "Alex Grönholm" <alex.gronh...@nextday.fi <mailto:alex.gronh...@nextday.fi>> wrote: O

Re: [Distutils] PEP 566 - metadata 1.3 changes

On the same note, wheel currently writes "2.0" as its metadata version. Shouldn't this be changed into 1.3 (along with ditching metadata.json)? Thomas Kluyver kirjoitti 12.01.2018 klo 17:26: On Wed, Jan 10, 2018, at 11:42 PM, Nick Coghlan wrote: On 11 January 2018 at 00:54, Daniel Holth

Re: [Distutils] Immutability of Release Metadata in Warehouse

Couldn't Warehouse validate the description, and reject the upload (with an appropriate message) if it doesn't pass? This at least would eliminate those ugly project pages that failed to render...there are a lot of them on PyPI. Donald Stufft kirjoitti 19.12.2017 klo 21:43: For those who are

[Distutils] Wheel 1.0 roadmap

I am planning for a 1.0.0 release of the "wheel" library. I would like to start using semver from this point onwards, which in the case of wheel means that its command line interface should be well defined and remain backwards compatible. As part of this effort, I've rewritten the

Re: [Distutils] How do native namespaces work? (And do they play well with setuptools?)

mas Nyberg kirjoitti 25.10.2017 klo 22:05: On 10/25/2017 04:54 PM, Alex Grönholm wrote: What do you mean by "using"? Are you referring to where I say "I'm currently using python 3.5 as packaged in debian 9"? (I can't find the string "using" anywhere else.) I j

Re: [Distutils] How do native namespaces work? (And do they play well with setuptools?)

What do you mean by "using"? You mean installing them (for which you should never use easy_install anyway, btw), or packaging them? The only limitation regarding packaging them is that you currently need to explicitly list them in your packaging configuration, as find_packages() does not yet

Re: [Distutils] Announcement: Pip 10 is coming, and will move all internal APIs

Paul Moore kirjoitti 21.10.2017 klo 13:03: On 20 October 2017 at 23:53, Richard Jones wrote: Hiya Paul, There's a bunch of tooling out there using pip's internals to extending pip's functionality. Could you please provide a some reasoning as to why they're all going to

Re: [Distutils] Announcement: Pip 10 is coming, and will move all internal APIs

Yeah, +1 from me too. Pip is one project where people will highly likely try out the pre-release versions. xoviat kirjoitti 20.10.2017 klo 20:34: +1 on pre-release wheels. I've seen the process in action with SciPy, and it helped to catch at least one significant bug. 2017-10-20 8:30

Re: [Distutils] Announcement: Pip 10 is coming, and will move all internal APIs

Perhaps pkg_resources.find_distributions()? http://setuptools.readthedocs.io/en/latest/pkg_resources.html#getting-or-creating-distributions Jannis Gebauer kirjoitti 20.10.2017 klo 16:55: Thanks for the heads-up, Paul. I’m currently using `pip.get_installed_distributions` and as far as I can

Re: [Distutils] Entry points: specifying and caching

Daniel Holth kirjoitti 18.10.2017 klo 21:06: http://setuptools.readthedocs.io/en/latest/formats.html?highlight=entry_points.txt#entry-points-txt-entry-point-plugin-metadata http://setuptools.readthedocs.io/en/latest/pkg_resources.html?highlight=pkg_resources#creating-and-parsing It is not

[Distutils] New wheel release (v0.30.0)

I have now made my first wheel release as the new maintainer. This release contains bug fixes and documentation updates. I decided to make a release now to get a fix out for some long standing issues. A proper overhaul of the documentation is coming later. The project has also been migrated

Re: [Distutils] (no subject)

Python 2.1 is very, very old and has not been supported for many years. It is doubtful that any currently available Python package will work with it. For future reference, when you ask for help with an error, always include the error message in your request. It would also be prudent to

Re: [Distutils] Migrating interoperability specs to packaging.python.org

Yes, I see the inclusion of a metadata file which conforms to an unaccepted PEP as potentially dangerous. Perhaps I should disable it in the next release? Daniel Holth kirjoitti 04.09.2017 klo 17:03: Some people enjoy using metadata.json which tracked pep 426 but I have been meaning to

Re: [Distutils] why do we still put version numbers into dist-info folders

the metadata at all when that data was not needed. We might always do listdir() for path in sys.path and parse every METADATA on the first pkg_resources import. On Fri, Sep 1, 2017 at 4:32 PM Alex Grönholm <alex.gronh...@nextday.fi <mailto:alex.gronh...@nextday.fi>> wrote: +1 for

Re: [Distutils] why do we still put version numbers into dist-info folders

+1 for getting rid of version numbers in the dist-info folders. RonnyPfannschmidt kirjoitti 01.09.2017 klo 20:32: Hi everyone, a while now i have wondered - why put version numbers into the dist info folders not only makes it lookup more expensive (need to search for a distribution->folder

Re: [Distutils] status check on PEP 517

with a stdlib module; it is confusing when it happens but it's also fairly avoidable. Sure but vendorizing the dependencies would work around the problem, yes? Like how setuptools does? On Sat, Jul 29, 2017, 17:38 Alex Grönholm <alex.gronh...@nextday.fi <mailto:alex.gronh...@nextday.fi&g

Re: [Distutils] PyPi’s predictable download url

Wes Turner kirjoitti 27.07.2017 klo 02:36: On Wednesday, July 26, 2017, Paul Moore > wrote: On 26 July 2017 at 15:52, Alexander Belopolsky wrote: > On Wed, Jul 26, 2017 at 10:21 AM, Nick Coghlan

Re: [Distutils] Maintenance of the "wheel" package

Okay. Will you give me the appropriate access privileges to do that? Daniel Holth kirjoitti 25.07.2017 klo 16:22: Fine by me, probably inevitable, obviously I'm not a fan of git. Please take care of the useful pending pull requests on bitbucket first. On Tue, Jul 25, 2017 at 9:05 AM Alex

[Distutils] Maintenance of the "wheel" package

Looking at the commit history, the maintenance of "wheel" has more or less stalled since 2016. I would like to volunteer myself as a co-maintainer of this project, if allowed. Here's my list of things I would like to do with it: * Move the project from Bitbucket to the PyPA organization on

Re: [Distutils] continuous integration options (was Re: Travis-CI is not open source, except in fact it *is* open source)

I don't know if it has been mentioned before, but Travis already provides a way to automatically package and upload sdists and wheels to PyPI: https://docs.travis-ci.com/user/deployment/pypi/ I've been using it myself in many projects and it has worked quite well. Granted, I haven't had to

Re: [Distutils] installing bagit-python from the Library of Congress GitHub

Pip is a command line tool. Are you trying to use it from the interactive Python interpreter instead? 30.10.2016, 18:01, Benjamin Houtman kirjoitti: Hello, I'm trying to install bagit-python from the LoC Github https://github.com/LibraryOfCongress/bagit-python

Re: [Distutils] Compatibility Tags and the Stable API

Am I understanding this correctly? Even though the limited API is supposed to work on all CPython versions supporting the numbered API, I cannot do the compiling using a newer version (say 3.5) or it won't work with older ones (3.3, 3.4)? 09.09.2016, 14:00, Daniel Holth kirjoitti: Correct.

Re: [Distutils] What role to eggs still play?

20.08.2016, 01:41, Chris Barker - NOAA Federal kirjoitti: Thanks, I think I'm getting it. About the toml file... the *-info metadata is a compiled artifact, according to all the existing Python packages. Most sdists even have a *.egg-info directory. If it's a compiled artifact, then

Re: [Distutils] What role to eggs still play?

19.08.2016, 20:25, Daniel Holth kirjoitti: Eggs are the only way to add a zipped distribution to PYTHONPATH and have setuptools find the metadata (the Python code can be found with or without the metadata; setuptools does not discover *.dist-info inside zip). Eggs are used by buildout,

Re: [Distutils] Deprecating little used file types/extensions on PyPI?

15.08.2016, 22:28, Donald Stufft kirjoitti: On Aug 15, 2016, at 3:22 PM, Ian Cordasco wrote: My only thought is how we convey this message to users. I wonder if it would be beneficial to have Twine cut a release that warns users when they are uploading something

Re: [Distutils] Deprecating little used file types/extensions on PyPI?

+1 for disallowing uploads of anything else than sdists and wheels. 15.08.2016, 22:09, Donald Stufft kirjoitti: Hello! I'd like to restrict what folks can upload to PyPI in an effort to help narrow the scope down and to enable more a more consistent experience for everyone. First off, we

Re: [Distutils] Proposal: "Install and save"

/src/tip/SConstruct https://bitbucket.org/dholth/cryptacular/src/tip/pyproject.toml On Sat, Jul 23, 2016 at 10:11 AM Alex Grönholm <alex.gronh...@nextday.fi <mailto:alex.gronh...@nextday.fi>> wrote: 23.07.2016, 17:04, Thomas Kluyver kirjoitti: > On Sat, Jul 23, 2016, at

Re: [Distutils] Proposal: "Install and save"

23.07.2016, 17:04, Thomas Kluyver kirjoitti: On Sat, Jul 23, 2016, at 02:32 PM, Alex Grönholm wrote: I'm -1 on this because requirements.txt is not really the standard way to list dependencies. In the Python world, setup.py is the equivalent of Node's package.json. But as it is Python code

Re: [Distutils] Proposal: "Install and save"

I'm -1 on this because requirements.txt is not really the standard way to list dependencies. In the Python world, setup.py is the equivalent of Node's package.json. But as it is Python code, it cannot so easily be programmatically modified. 22.07.2016, 20:48, Chris Angelico kirjoitti: In

Re: [Distutils] Missing IPv6 support on pypi.python.org

The legacy software might have issues with IPv6 so I doubt this will happen before Warehouse replaces Cheeseshop as the new PyPI. 13.07.2016, 15:42, Baptiste Jonglez kirjoitti: As a follow-up, Fastly now provides an option to enable IPv6 (but this is not enabled by default). See:

Re: [Distutils] matrix: python_versions x supported_plattforms, cross-compiling vs VM

This reminds me of something I wanted to ask – how come the "virtualenv" tool installs wheel but the built-in "venv" tool does not? The latter is the currently recommended method of creating a virtualenv, isn't it? 27.05.2016, 19:40, Donald Stufft kirjoitti: On May 27, 2016, at 12:37 PM, Paul

Re: [Distutils] If you want wheel to be successful, provide a build server.

Amen to that, but who will pay for it? I imagine a great deal of processing power would be required for this. How do implementors of other languages handle this? 25.05.2016, 10:13, Thomas Güttler kirjoitti: If you want wheel to be successful, **provide a build server**. Quoting the author of

Re: [Distutils] comparison of configuration languages

10.05.2016, 19:35, Ethan Furman kirjoitti: On 05/10/2016 08:41 AM, Alex Grönholm wrote: 10.05.2016, 18:26, Ethan Furman kirjoitti: Please no. I'd rather do xml than yaml. Why do you hate it so much? I strongly prefer YAML to anything else I've seen here. It's too complicated and error

Re: [Distutils] comparison of configuration languages

10.05.2016, 18:26, Ethan Furman kirjoitti: On 05/10/2016 08:14 AM, Donald Stufft wrote: On May 10, 2016, at 11:00 AM, Antoine Pitrou wrote: (as an aside, if there's the question of forking an existing parser implementation for better vendorability, forking a YAML parser may be more useful to

Re: [Distutils] comparison of configuration languages

10.05.2016, 18:14, Donald Stufft kirjoitti: On May 10, 2016, at 11:00 AM, Antoine Pitrou wrote: (as an aside, if there's the question of forking an existing parser implementation for better vendorability, forking a YAML parser may be more useful to third-party folks than

Re: [Distutils] comparison of configuration languages

10.05.2016, 18:00, Antoine Pitrou kirjoitti: On Tue, 10 May 2016 10:55:38 -0400 Donald Stufft wrote: I think TOML is more usable than ConfigParser and in particular I think that the adhoc post processing step makes ConfigParser inherently less usable because it forces a

Re: [Distutils] comparison of configuration languages

This looks very close to what I'd like to have, but then we'd have the situation of an uncommon format with no tooling support, won't we? Assuming the actual config file is in xaml format. 10.05.2016, 02:56, Ethan Furman kirjoitti: On 05/06/2016 07:59 PM, Nathaniel Smith wrote: Here's that

Re: [Distutils] comparison of configuration languages

10.05.2016, 12:43, Ionel Cristian Mărieș kirjoitti: On Tue, May 10, 2016 at 10:38 AM, Alex Grönholm <alex.gronh...@nextday.fi <mailto:alex.gronh...@nextday.fi>> wrote: So far the ONLY objective problems with YAML seems to be the problematic implementation

Re: [Distutils] comparison of configuration languages

A few facts: * YAML is good enough for Salt, Ansible and numerous other common tools * The YAML standard has been stable for many years, unlike TOML which still hasn't even reached 1.0 * YAML has widespread tooling support, unlike TOML We all agree that JSON is not the solution. No

Re: [Distutils] comparison of configuration languages

This is fine as long as developer convenience does not suffer. Underlying implementations can always be improved, but if we decide on a sucky format, we'll have to live with that for a long time. 08.05.2016, 08:07, Chris Barker kirjoitti: On Sat, May 7, 2016 at 6:04 PM, Brett Cannon

Re: [Distutils] comparison of configuration languages

08.05.2016, 02:08, Donald Stufft kirjoitti: On May 7, 2016, at 7:05 PM, Alex Grönholm <alex.gronh...@nextday.fi <mailto:alex.gronh...@nextday.fi>> wrote: 07.05.2016, 17:48, Nick Coghlan kirjoitti: On 7 May 2016 13:00, "Nathaniel Smith" <n...@pobox.com> wro

Re: [Distutils] comparison of configuration languages

07.05.2016, 17:48, Nick Coghlan kirjoitti: On 7 May 2016 13:00, "Nathaniel Smith" > wrote: > > Here's that one-stop writeup/comparison of all the major configuration > languages that I mentioned: > >

Re: [Distutils] comparison of configuration languages

+1. I don't think the pathological cases of YAML syntax are of any concern in this context. Plus it has excellent tooling support, unlike TOML. 07.05.2016, 09:25, Fred Drake kirjoitti: On May 6, 2016, at 10:59 PM, Nathaniel Smith wrote: Here's that one-stop writeup/comparison

Re: [Distutils] moving things forward

. Enforced staticness of the build script is right out. On Thu, May 5, 2016 at 4:34 PM Alex Grönholm <alex.gronh...@nextday.fi <mailto:alex.gronh...@nextday.fi>> wrote: I think it would be best to gather a few extreme examples of setup.py files from real world projects and figure out

Re: [Distutils] moving things forward

I think it would be best to gather a few extreme examples of setup.py files from real world projects and figure out if they can be implemented in a declarative fashion. That at least would help us identify the pain points. For starters, gevent's setup.py looks like it needs a fair bit of

Re: [Distutils] moving things forward

Different files for what? Something not covered by PEP 508? 05.05.2016, 02:23, Ethan Furman kirjoitti: On 05/04/2016 03:28 PM, Paul Moore wrote: On 4 May 2016 at 23:11, Chris Barker wrote: That basically repeats the mistake that was made with setup.py. We explicitly don't want an

Re: [Distutils] moving things forward

I certainly have no problem with Daniel's suggestion (and it would be much better than my solution) but would involve yet more standards work. Who's going to do that and when? 03.05.2016, 22:39, Donald Stufft kirjoitti: On May 3, 2016, at 3:35 PM, Daniel Holth wrote: Who

Re: [Distutils] moving things forward

r make that possible. On Tue, May 3, 2016 at 2:29 PM Alex Grönholm <alex.gronh...@nextday.fi <mailto:alex.gronh...@nextday.fi>> wrote: No, setuptools parses the install requirements before acting on setup requirements. That is the source of the problem. If setuptools only parsed

Re: [Distutils] moving things forward

kirjoitti: On 3 May 2016 at 15:07, Alex Grönholm <alex.gronh...@nextday.fi <mailto:alex.gronh...@nextday.fi>> wrote: Having setuptools process the setup requirements before parsing install requirements would be a good step forward. Had that been done before, we could'v

Re: [Distutils] moving things forward

Having setuptools process the setup requirements before parsing install requirements would be a good step forward. Had that been done before, we could've just added a setup requirement for a newer setuptools to enable PEP 508 conditional requirements. 03.05.2016, 21:04, Daniel Holth

Re: [Distutils] Two ways to download python packages - I prefer one

You make it sound like there's a plausible alternative to setuptools entry points -- is there? 02.05.2016, 10:14, Noah Kantrowitz kirjoitti: The correct way to do that these days is `pip install -e .` AFAIK. Setuptools should be considered an implementation detail of installs at best, not

Re: [Distutils] wheel including files it shouldn't

To what end? 28.04.2016, 21:21, Barry Warsaw kirjoitti: On Apr 27, 2016, at 10:00 PM, Alex Grönholm wrote: The sdist should include all the source files, including tests and documentation. In binary distributions, however, they are just dead weight. Do you want the full documentation and test

Re: [Distutils] wheel including files it shouldn't

. 27.04.2016, 21:40, Ethan Furman kirjoitti: On 04/27/2016 11:13 AM, Alex Grönholm wrote: Are you seriously saying that you want your bdists to include tests, documentation etc.? However you and I agree or disagree on what should be in a bdist, the command I ran should have produced a bdist based

Re: [Distutils] wheel including files it shouldn't

Are you seriously saying that you want your bdists to include tests, documentation etc.? Most developers would not agree with you, including yours truly. 27.04.2016, 21:10, Ethan Furman kirjoitti: On 04/27/2016 10:52 AM, Donald Stufft wrote: This isn't really a problem with what you're

Re: [Distutils] Name arbitration on PyPI

Here: https://pypi.python.org/pypi/PIL It was downloadable until external downloads were disallowed. 19.04.2016, 01:49, Chris Barker - NOAA Federal kirjoitti: Another high profile example of such a project: PIL. Was PIL ever on PyPi? Anyway, yup, the solution there was to fork give it s

Re: [Distutils] Name arbitration on PyPI

Another high profile example of such a project: PIL. 19.04.2016, 00:56, Chris Barker kirjoitti: On Mon, Apr 18, 2016 at 2:31 PM, Ian Cordasco > wrote: >> 1. PyYAML is a package that would be de-registered in such a scheme.

Re: [Distutils] The mypy package

I've fallen into this trap as well, so +1 for the takeover. It might be a good idea to come up with a standardized process for taking over old, unmaintained packages. 16.04.2016, 02:29, Guido van Rossum kirjoitti: Brett suggested I ask the kind folks here. As you may or may not know,

Re: [Distutils] 'Invalid module name' creating package with setuptools

If you get that error, it means you're not actually using python 3 to run setup.py. 15.04.2016, 09:52, Luí­s de Sousa via Distutils-SIG kirjoitti: Hi Marius, thank you for the reply. If I remove the line # coding=utf8, I get the following error: $ python setup.py bdist_wheel --universal

Re: [Distutils] pip install -e foo (without Repo URL)

To my knowledge, metadata 2.0 does not have any reliable means to specify a repository URL. So how do you propose to retrieve this information? 15.04.2016, 13:05, Thomas Güttler kirjoitti: Am 14.04.2016 um 14:31 schrieb Ian Cordasco: On Apr 14, 2016 2:20 AM, "Thomas Güttler"

Re: [Distutils] 'Invalid module name' creating package with setuptools

That setup.py worked fine here, so I'm guessing this is not the actual setup.py you're running. What is the exact value of the "name" argument in your real setup.py? BTW, source encoding is utf-8 by default on Python 3 so the "# coding=utf8" is unnecessary. 14.04.2016, 18:28, Luí­s de Sousa

Re: [Distutils] How to deprecate a python package

You can already modify the description and add the "Development Status :: 7 - Inactive" classifier. It would be really nice to filter these out of search results though. 06.04.2016, 02:32, Greg Ewing kirjoitti: Geoffrey Spear wrote: I don't have an answer to your actual question, but I'd not

Re: [Distutils] How to deprecate a python package

with the package. On 4/5/2016 18:40, Alex Grönholm wrote: Wouldn't my suggestion or Glyph's be easier for the maintainers? That way they wouldn't even have to make a new release, just modify a setting on the package settings page on PyPI. Also, are you going you see the warning if it's emitted

Re: [Distutils] How to deprecate a python package

Wouldn't my suggestion or Glyph's be easier for the maintainers? That way they wouldn't even have to make a new release, just modify a setting on the package settings page on PyPI. Also, are you going you see the warning if it's emitted on installation? 06.04.2016, 01:37, Alexander Walters

Re: [Distutils] How to deprecate a python package

The author of the package the OP referred to has not chosen to add any status classifier or any kind of warning in the description that would notify the user of its deprecated status. 06.04.2016, 01:05, Tres Seaver kirjoitti: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/05/2016 04:1

Re: [Distutils] How to deprecate a python package

I think an ideal solution would be to add a feature to Warehouse that would "redirect" any downloads of a library to another. Though I'm not saying it would be simple. 05.04.2016, 22:59, Ionel Cristian Mărieș kirjoitti: What's wrong with a new release that just depends on replacement

Re: [Distutils] Thank you for the ability to do `pip install git+https://...`

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.gronh...@nextday.fi> wrote: You could always point pip to the automatically generated zip

Re: [Distutils] Thank you for the ability to do `pip install git+https://...`

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

[Distutils] Wheels and Python implementation markers

What is the "correct" way to specify (for building wheels) in setup.py that a dependency should only be installed on CPython? If so, how should I go about it? Nothing I've tried seems to work right. The python_implementation marker worked up until packaging 16.5 and then

Re: [Distutils] question about future pip capabilities

10.12.2009 19:18, Darren Dale kirjoitti: Hello, I apologize for cross-posting. I am working on improving how I distribute a few python packages, and in the process I have run into some questions that involve easy_install, setuptools/distribute/, pip, and the relationships between them. I was

Re: [Distutils] Deleting build directory

Tarek Ziadé kirjoitti: On Sat, Nov 14, 2009 at 5:06 AM, Ben Finney ben+pyt...@benfinney.id.au wrote: cool-RR cool...@cool-rr.com writes: What I really want is never having to worry about the build directory being around after doing any actions with `setup.py`. Do you have any other

Re: [Distutils] People want CPAN :-)

Andreas Jung kirjoitti: Am 06.11.09 18:53, schrieb Guido van Rossum: I just found this comment on my blog. People have told me this in person too, so I believe it is real pain (even if the solution may be elusive and the suggested solutions may not work). But I don't know how to improve the

Re: [Distutils] Setuptools 0.6c10 released

P.J. Eby kirjoitti: The long-overdue setuptools 0.6c10 update is now available on PyPI, at: http://pypi.python.org/setuptools/ Major updates and fixes include: * Support for SVN 1.6 and Python 2.6 * Fix for the Python 2.6.3 build_ext API change * Support for the most recent Sourceforge

Re: [Distutils] distribute equivalent of setup.py develop?

Andreas Klöckner kirjoitti: Hi there, I've recently tried distribute, and much to my dismay found that it doesn't appear to contain an equivalent of setup.py develop. Is such a thing planned, or, even better, available now? You must be mistaken. Distribute definitely has such a command.

Re: [Distutils] distribute equivalent of setup.py develop?

Andreas Klöckner kirjoitti: On Donnerstag 15 Oktober 2009, Andreas Klöckner wrote: Hi there, I've recently tried distribute, and much to my dismay found that it doesn't appear to contain an equivalent of setup.py develop. Is such a thing planned, or, even better, available now? Ah,

Re: [Distutils] Setuptools 0.6c10 release imminent; please test

sstein...@gmail.com kirjoitti: On Oct 12, 2009, at 4:25 PM, P.J. Eby wrote: But before you do that, be sure to uninstall Distribute completely Damn if I understand this...such a long time waiting for all these bug fixes...so little action, so much angst... Then that all that effort going

Re: [Distutils] tracking requested vs dependency installs in PEP 376 metadata

Ronald Oussoren kirjoitti: On 11 Oct, 2009, at 16:27, Lennart Regebro wrote: 2009/10/11 Ronald Oussoren ronaldousso...@mac.com: What about packages that are installed as a dependency of some other package and then used in user scripts without an explict depency on them? That is, I install

Re: [Distutils] Packaging Distribute

Chris Withers kirjoitti: Tarek Ziadé wrote: 1- we ship 0.7 under a new name - e.g. like distribute2 You could even take the opportunity to rename it completely to something that makes sense ;-) While I agree that the name was badly chosen (for reasons you outline below), a name change at

Re: [Distutils] tracking requested vs dependency installs in PEP 376 metadata

Carl Meyer kirjoitti: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Toshio Kuratomi wrote: I would say REQUESTED due to my arguments for not recording installed-as-package-dependency. REQUESTED is fine, but I don't understand how the arguments apply, given that I'm not proposing to

Re: [Distutils] the virtualenv-distribute mess

kiorky kirjoitti: Tarek Ziadé a écrit : On Fri, Oct 9, 2009 at 2:43 PM, kiorky kio...@cryptelium.net wrote: Hi tarek, Tarek Ziadé a écrit : The *whole* point of Distribute 0.6.x is to be backward compatible, meaning that if virtualenv switch to it, you will not even notice

Re: [Distutils] Package install failures in 2.6.3 - setuptools vs Distribute

P.J. Eby kirjoitti: At 11:53 AM 10/5/2009 +0200, Lennart Regebro wrote: 2009/10/5 Jeff Rush j...@taupro.com: Very unfortunate, as in, it should NOT have happened. And *especially* without any announcement on python.org or mention on the python-committers list of something this major.

Re: [Distutils] Package install failures in 2.6.3 - setuptools vs Distribute

Jeremy Sanders kirjoitti: K. Richard Pixley wrote: Ronald Oussoren wrote: For beginners this issue is a showstopper that they cannot resolve without help. I'm a relative beginner to distutils/setuptools/distribute, but a long time configuration/build/packaging professional.

Re: [Distutils] Package install failures in 2.6.3 - setuptools vs Distribute

Bill Janssen kirjoitti: Zooko Wilcox-O'Hearn zo...@zooko.com wrote: I'm struggling to articulate something here. When the maintainer of the stable branch of a platform that I rely on says The fact that upgrading to our recent stable release will break this critical functionality is

Re: [Distutils] Package install failures in 2.6.3 - setuptools vs Distribute

Bill Janssen kirjoitti: Alex Grönholm alex.gronh...@nextday.fi wrote: Does your bug still exist in Distribute? If so, please report it at http://bitbucket.org/tarek/distribute/ (assuming that bitbucket is operational, which it currently isn't) Sorry, Alex, I don't know about

Re: [Distutils] SIP/PyQt and distutils

Jeremy Sanders kirjoitti: Zooko Wilcox-O'Hearn wrote: I'm not sure that you really need to explicitly invoke g++ for anything nowadays. Modern gcc notices that the input is C++ and compiles it accordingly. Could you be more specific about what doesn't work? It does work, but prints

Re: [Distutils] Installing stdeb on vanilla Ubuntu

Olof Bjarnason kirjoitti: Hi distutils! So I'm quite sure stdeb is the tool for py2deb I'm looking for. What are the correct steps of installing this tool, assuming Ubuntu9.04. I guess I need this: 1. Python (check) 2. distutils (check) Distutils is a part of the standard library, so you

  1   2   >