[Distutils] buildout: build options for dependencies of recipes

Hi all The zc.recipe.egg:custom recipe allows the specification of build options for a custom egg. But what do we do if we want to specify custom build options for an egg that is a dependency of a recipe (or perhaps the recipe itself)? Case in point We have a recipe, erp5.recipe.mysqldatabase,

[Distutils] M2Crypto install failing

Hi, With this simple buildout: [buildout] parts = m2c [m2c] recipe = zc.recipe.egg eggs = M2Crypto I'm getting this failure: Installing 'M2Crypto'. We have no distributions for M2Crypto that satisfies 'M2Crypto'. Getting distribution for 'M2Crypto'. Running easy_install: /usr/bin/python

Re: [Distutils] New buildout options: checksums and allow-omitted-checksums

Hi Thomas, I like your idea in general. I'd like to point to the following suggestion with patch+test (though it might need some cleanup) that is not exactly related to what you're proposing, but has to do with the same thing (relationship between files and checksums):

Re: [Distutils] reservations about pythonv

Another variant of this case, one we're actually facing here at our company (Nexedi) right now, is when you need to compile extension modules with libraries that are newer than the ones in the system, and you don't have root access. The absense of LD_LIBRARY_PATH means a segfault on an arbitrary

Re: [Distutils] reservations about pythonv

Hi Carl, On Sun, Mar 20, 2011 at 04:06, Carl Meyer c...@oddbird.net wrote: Hi Leonardo, On 03/19/2011 08:18 PM, Leonardo Rochael Almeida wrote: Another variant of this case, one we're actually facing here at our company (Nexedi) right now, is when you need to compile extension modules

Re: [Distutils] issues with namespace packages on Debian Squeeze and Python 2.6

Maybe not a debian-specific workaround, but a setting like: [buildout] additional-site-packages = /usr/lib/python2.6/dist-packages /usr/local/lib/python2.6/dist-packages On Wed, Mar 23, 2011 at 14:42, Reinout van Rees rein...@vanrees.org wrote: On 22-03-11 18:57, Carl Meyer

[Distutils] buildout: overriding the global [versions] section

Hi, It seems I cannot override, for a single buildout part, the version information of the global [versions] section. Is this possible and I just overlooked something? If not, I intend to add support for that on zc.recipe.egg and/or z3c.recipe.scripts recipes. Any comments? And where can I

Re: [Distutils] Buildout: adding a link to a compiled library: uno

Hi Alessandro, If you are going to use the Python that comes with your distribution (usually referred to as 'System Python'), and that you want to use the uno library that comes with this System Python, that is, you can do something like: $ python Python 2.6.6 (r266:84292, Sep 15 2010, 16:22:56)

Re: [Distutils] Better version pinning in buildout (buildout-versions)

Hi I see one major issue with this proposal: Currently, the fact that the versions are in a standard buildout section, and subject to standard extends layering rules for buildout, means we have two great features: 1. You could locally override the versions file by just providing a few extra

Re: [Distutils] Better version pinning in buildout (buildout-versions)

On Mon, Jan 7, 2013 at 12:57 PM, Marius Gedminas mar...@pov.lt wrote: [...] Also, having two similar but slightly distinct mechanisms for version pinning? I'm -1 on that. Yeah, that too (so, overall, a -2 from me :-) It's one more place to check for/maintain version pin information. The

Re: [Distutils] Proposal for incorporating buildout-versions on buildout (Re: Better version pinning in buildout (buildout-versions))

Hi, On Tue, Jan 15, 2013 at 10:21 AM, Eric V. Smith e...@trueblade.com wrote: [...] I guess I don't understand: I don't know how hard it'd be top implement but in an ideal world I'd prefer to see develop eggs trump any other sources but still have version requirements checked. I think it

Re: [Distutils] [RFC] support configure + make pattern in distutils (or setuptools)

Sounds nice, Looks like it could make building distributions based on c-libraries more predictable (think lxml or pymsql), specially when you explicitly want to avoid libraries provided by the system. Of course, it would only be helpful for me if buildout grew support for tweaking it somehow.

Re: [Distutils] Support for condition to include or exclude a buildout sections based on a Python expression

How easy it is to know which sections are actually used during a run? Also, it would be nice to have this info on the output of buildout annotate On Wed, Jan 30, 2013 at 12:18 PM, Philippe Ombredanne pombreda...@nexb.com wrote: On Wed, Jan 30, 2013 at 1:39 PM, Jim Fulton j...@zope.com wrote:

Re: [Distutils] PEP-426 environment markers [was: Re: Support for condition to include or exclude a buildout sections based on a Python expression]

Even on 64 bit windows? On Wed, Jan 30, 2013 at 2:37 PM, Daniel Holth dho...@gmail.com wrote: One more thing: sys.platform != 'win32' is how you write not windows On Wed, Jan 30, 2013 at 10:13 AM, Daniel Holth dho...@gmail.com wrote: On Wed, Jan 30, 2013 at 9:58 AM, Jim Fulton j...@zope.com

Re: [Distutils] RFC: Egg cache fro self-contained buildout

+1 This is potentially useful for Heroku or Google Apps, or anything that requires all your files to exist inside the build area after build time from where it creates the blob that is actually pushed to all the slaves. On Mon, May 13, 2013 at 4:26 PM, Daniel Holth dho...@gmail.com wrote:

Re: [Distutils] PEP470, backward compat is a ...

I wish there was a way to automatically redirect people requesting PIL to get Pillow instead. It's a PYPI/setuptools friendly repackaging of PIL that has been going on for years now: https://pypi.python.org/pypi/Pillow/2.4.0 On 19 May 2014 23:29, Donald Stufft don...@stufft.io wrote: Just an

Re: [Distutils] Standard packaging API? (was Re: Are there any plans to move to pip/wheels in buildout?)

I thought distlib was supposed to be that API... Even though pip doesn't use it. Though that would mean a new major version of buildout that worked on wheels exclusively instead of eggs. Pip itself has an internal API in the `pip.commands` package. From a casual glance it seems usable from other

Re: [Distutils] Are there any plans to move to pip/wheels in buildout?

On 2 December 2014 at 10:53, Reinout van Rees rein...@vanrees.org wrote: [...] Something I don't understand here is that there *is* a single version list. And so it feels like it doesn't really matter that much if you just lump all the packages together (like pip does). FWIW, In the past

Re: [Distutils] How to implement ‘setup.py’ functionality that itself needs third-party distributions

I have faced an issue with setuptools (and even plain distutils) in the past that has some resemblance to this. There was a PyPI package that contained C extensions and headers, and another python package that had more C extensions, but depended on the location of the headers on the first package

Re: [Distutils] setup_requires for dev environments

On 18 March 2015 at 14:37, Daniel Holth dho...@gmail.com wrote: [...] The behavior we're aiming for would be: installer run setup.py - installs things python setup.py - does not install things Besides that, I'd add that we're also looking for: python setup.py (by itself) should not raise

Re: [Distutils] Dynamic linking between Python modules (was: Beyond wheels 1.0: helping downstream, FHS and more)

On 19 May 2015 at 13:28, Chris Barker chris.bar...@noaa.gov wrote: [...] So is it possible for PyPA to grow the features to mange all the python bits, and then have things like conda use pip inside of Anaconda, maybe? or SOME transition where you can add conda if and only if you need its

Re: [Distutils] Working toward Linux wheel support

Hi Tres, On 21 July 2015 at 00:25, Tres Seaver tsea...@palladion.com wrote: [...] Even given the over-specified platform tags Nick suggests, linux wheels won't fully work, because the build-time depes won't be satisfiable *by pip*: the burden will be on each project to attempt a build and

Re: [Distutils] Working toward Linux wheel support

Hi, On 17 July 2015 at 05:22, Nick Coghlan ncogh...@gmail.com wrote: On 17 July 2015 at 03:41, Nate Coraor n...@bx.psu.edu wrote: [...] As mentioned in the wheels PR, there are some questions and decisions made that I need guidance on: - On Linux, the distro name/version (as

Re: [Distutils] A smaller step towards de-specializing setuptools/distutils

This is a nice idea. It makes it easy to fix problematic `setup.py` files like this [1]: ``` from distutils.core import setup, Extension import numpy setup(ext_modules=[Extension("_cos_doubles", sources=["cos_doubles.c", "cos_doubles.i"], include_dirs=[numpy.get_include()])]) ```

Re: [Distutils] build system abstraction PEP, take #2

On 17 November 2015 at 13:20, Daniel Holth wrote: > LGTM > > Q: Why is build_command a list? > Q: Why isn't the file name venezuelanbeavercheese.json instead of > pypa.json? > Or why not just use a specific key in setup.cfg instead of a pypa.json file? ISTM that this PEP

Re: [Distutils] Which Build Distribution Formats do exist?

There are other formats also. This distutils doc explain the "native" ones: https://docs.python.org/2/distutils/builtdist.html On 4 November 2015 at 21:09, Alexander Walters wrote: > > > On 11/4/2015 15:13, Thomas Güttler wrote: > >> From >>

Re: [Distutils] Which Build Distribution Formats do exist?

Hi Thomas On 5 November 2015 at 17:42, Thomas Güttler <guettl...@thomas-guettler.de> wrote: > Am 05.11.2015 um 14:12 schrieb Leonardo Rochael Almeida: > > There are other formats also. This distutils doc explain the "native" > ones: > > > > https://do

Re: [Distutils] Working toward Linux wheel support

Hi, Going back in time to this old post, but I think it becomes more relevant now that Nate's work is being completed: On 13 August 2015 at 22:47, Nathaniel Smith <n...@pobox.com> wrote: > On Thu, Aug 13, 2015 at 12:30 PM, Leonardo Rochael Almeida > <leoroch...@gmail.com> wr

Re: [Distutils] Working toward Linux wheel support

September 2015 at 16:22, Donald Stufft <don...@stufft.io> wrote: > On September 8, 2015 at 3:21:26 PM, Leonardo Rochael Almeida ( > leoroch...@gmail.com) wrote: > > > > Still, I wouldn't want a random binary wheel suddenly finding its way > into > > my servers,

Re: [Distutils] Problems using pip on Ubuntu when 2.7, 3.4 and 3.5 are installed

Hi Mr(s) Versions, Your "locate" output shows that you have a manual installation of Python 3.4 on /usr/local, and it's possible that "/usr/local/bin" is ahead of "/usr/bin" in your PATH, which is why pip3 installs into Python 3.4. >From your error message with Python 3.5, it seems like your

[Distutils] Fwd: setup('postinstall'='my.py')

Re-sending to the list as well: -- Forwarded message -- From: Leonardo Rochael Almeida <leoroch...@gmail.com> Date: 3 February 2016 at 16:23 Subject: Re: [Distutils] setup('postinstall'='my.py') To: Alt Sheets <altshe...@gmail.com> Hi, [...] On 3 February 2016 a

Re: [Distutils] setup('postinstall'='my.py')

Hi, The thing about setup.py is that it only runs at "build time". However, it looks like you want to generate a unique id at every install. Since you mentioned a windows installer, consider adding some code to the installer itself so that it calls an entry point in your library to generate

Re: [Distutils] draft PEP: manylinux1

Hi Nathaniel and Robert, This is a really nice proposal. I would only like to see added to this proposal (or another one) that new versions of installers should offer an option to opt in or out of binary packages from specific sources. Right now pip has the switches: - --no-binary -

Re: [Distutils] moving things forward (was: wheel including files it shouldn't)

On 6 May 2016 at 13:15, Chris Barker wrote: > On Fri, May 6, 2016 at 5:41 AM, Nick Coghlan wrote: > >> [...] > > > >> So rather than saying "the bootstrapping dependency declaration file >> is Python-but-not-really", it's easier to say "it's an

Re: [Distutils] comparison of configuration languages

In all this talk about using a YAML subset, I'm surprised no one mentioned YAMLish: https://pypi.python.org/pypi/yamlish It is a well defined subset of YAML and there are implementations in other programming languages. The problem with the 200+-lines-single-file library above is that it depends

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

Actually, another thing you can do with the wheels at this point is to take them for a spin :-) Have pip in another virtualenv install it by using --find-links, or even setting your own local index. If you have tests embedded in your wheel, now would be a good time to run them. Best regards,

Re: [Distutils] Outdated packages on pypi

We've been discussing here at least two different problems related to package maintainership: 1. Abandoned/no-longer-maintained, but previously useful packages 2. namespace and package idea space pollution due to tests/aborted attempts/packaginginexperience. I don't have a good idea about 1,

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

On 19 August 2016 at 14:14, Paul Moore wrote: > [...] > > So, the plan becomes: > > 1. Change Python 3.6 to default to .tar.gz on Windows > 2. Change setuptoos to default to .tar.gz, to catch users of older versions > 3. Document how to create a source distribution as

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

Thanks Daniel, A few corrections and considerations below: On 16 August 2016 at 09:50, Daniel Holth wrote: > Wheel should be updated to support the egg use case before egg is removed. > IIUC this would mostly mean officially supporting 'unzipped wheel' as a > thing you can

[Distutils] Future of setuptools and buildout

Spinning this off into its own thread... On 16 August 2016 at 13:10, Donald Stufft <don...@stufft.io> wrote: > > On Aug 16, 2016, at 11:15 AM, Leonardo Rochael Almeida < > leoroch...@gmail.com> wrote: > > Specifically, buildout right now has setuptools as its only depe

Re: [Distutils] Module Installation Issues

On 13 September 2016 at 19:00, Paul Moore wrote: > [...] > > I'm not honestly sure how big the "installing while a process is > running" issue would be - I did a few simple experiments and couldn't > immediately trigger weirdness, but I believe it can happen. And things >

Re: [Distutils] Buoldout2 e setup.py: install_requires ignored

Hi Sandro, I don't know what your previous setup did, but in your current setup, your `buildout.cfg` is not configured to take your `setup.py` into account in any way. In the `eggs` setting, only `django`, `ipython` and `django-settings` are mentioned. To take your `setup.py` into account it

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

On 24 August 2016 at 12:56, Daniel Holth wrote: > On Wed, Aug 24, 2016 at 10:41 AM Alex Grönholm > wrote: > >> [...] >> > > 19.08.2016, 20:25, Daniel Holth kirjoitti: > > Eggs are the only way to add a zipped distribution to PYTHONPATH and have >

Re: [Distutils] [proposal] version-free + lookup-friendly dist-info location

On 17 March 2017 at 11:47, Paul Moore wrote: > On 17 March 2017 at 14:40, Nick Coghlan wrote: > > [...] whichever > > version of "foo" is first on sys.path will "win", and you won't be able > to > > import from the other one (so you'll be able to import

Re: [Distutils] Canonical Repo URL: Make "pip install -e foo" work

Hi Thomas, Besides figuring out where the repo url is, you have a second problem to solve: The command `pip install -e some/path` already has something unpacked/checked-out in `some/path` to install in development mode. In which folder would the command `pip install -e some.project`

Re: [Distutils] [proposal] version-free + lookup-friendly dist-info location

On 17 March 2017 at 07:32, Paul Moore wrote: > On 17 March 2017 at 09:58, Ronny Pfannschmidt < > opensou...@ronnypfannschmidt.de> wrote: > > [...] > > in order to address that i'd like to propose to switch > > > > from "{distribution}-{version}.dist-info/" to >

Re: [Distutils] install_requires setup.py install vs pip install

Hi Tim, The reason setuptools can't process your package is because setuptools itself doesn't yet know how to install wheels[1] which pip knows how to install, and PyQT5 is only available as wheels on PyPI (the files with `.whl` extension in the `simple` URL you linked). [1]

Re: [Distutils] Getting dependecies of package from PyPiJSON

Hi Jeremy, On 20 July 2017 at 10:22, Jeremy Stanley wrote: > On 2017-07-20 14:55:53 +0200 (+0200), Krzysiek Płachno wrote: > [...] > > > > Or is it possible to this data in any other way (apart from > > downloading package)? > > Unfortunately, no, not with the current state

Re: [Distutils] status check on PEP 517

Hi Thomas, On 28 July 2017 at 16:53, Thomas Kluyver wrote: > > [...] I have a nagging concern about something that someone mentioned ages > ago: does it make sense for building sdists and building wheels to be part > of the same backend? > > [...] > > So I'd like us to

Re: [Distutils] PEP 517: Bootstrapping setuptools

Hi, On Mon, Aug 21, 2017 at 5:39 PM, xoviat wrote: > This statement comes from something that Donald said: >> >> > The unvendoring means that setuptools and the project code are now >> competing over who gets to define what an acceptable version is for these >> libraries to be

Re: [Distutils] Provisionally accepting PEP 517's declarative build system interface

Hi, On 29 May 2017 at 04:05, Nathaniel Smith wrote: > On Sun, May 28, 2017 at 10:37 PM, Donald Stufft wrote: > > > > [...] > > > > 1. Using the {package-name}-{package-version}.dist-info in the > > get_wheel_metadata() metadata is a mistake I think. In pip

Re: [Distutils] PEP 517: Bootstrapping setuptools

On 23 August 2017 at 01:37, Nick Coghlan wrote: > [...] > > Bootstrapping self-hosted packaging tools is a genuinely hard problem > True, but on the other hand, it's the self-hosted packaging tools' own problem. It's up to the tools themselves to solve it. if PEP 517 simply

Re: [Distutils] Fwd: Re: PEP 517 again

On 24 August 2017 at 10:41, xoviat wrote: > On Aug 24, 2017 8:28 AM, "Thomas Kluyver" wrote: > >> On Thu, Aug 24, 2017, at 02:21 PM, xoviat wrote: >> >> I mean is this golang or Python? In Python, you raise notimplementederror. >> >> >> But there's a

Re: [Distutils] PEP 517 again

On 24 August 2017 at 10:28, Thomas Kluyver wrote: > On Thu, Aug 24, 2017, at 02:21 PM, xoviat wrote: > > I mean is this golang or Python? In Python, you raise notimplementederror. > > > But there's a NotImplemented singleton in Python as well. The argument for > using a

Re: [Distutils] Fwd: Re: PEP 517 again

On 24 August 2017 at 15:13, Thomas Kluyver wrote: > On Thu, Aug 24, 2017, at 06:20 PM, Daniel Holth wrote: > > On Thu, Aug 24, 2017 at 12:34 PM Thomas Kluyver > wrote: > > Is there a reason to ask for an 'unclean' build, though? There may be a >

Re: [Distutils] PEP 517 again

On 25 August 2017 at 18:02, xoviat wrote: > While we're waiting for others to respond, what are we going to do with > respect to the sys.path issue? I don't think there has been discussion on > that yet. > There was plenty of discussion. The summary is: - removing srcdir

Re: [Distutils] [proposal] shared distribution installations

Hi, On 31 October 2017 at 05:22, Nick Coghlan wrote: > On 31 October 2017 at 05:16, RonnyPfannschmidt < > opensou...@ronnypfannschmidt.de> wrote: > >> Hi everyone, >> >> since a while now various details of installing python packages in >> virtualenvs caused me grief >> >>

[Distutils] Re: org-mode README file formats

On 8 May 2018 at 15:00, Diane Trout wrote: > On Tue, 2018-05-08 at 16:44 +, Brett Cannon wrote: > > > > On Mon, 7 May 2018 at 16:54 Diane Trout wrote: > > Hi, > > I was building a package where I had a README.org file, which > setuptools couldn't find. > > It

Re: [Distutils] Disabling non HTTPS access to APIs on PyPI

By the way, some pages on pypi itself are pointing to http: See, e.g. the "Download URL:" link here: https://pypi.python.org/pypi/google-appengine On 27 October 2017 at 17:22, Nathaniel Smith wrote: > On Oct 27, 2017 11:49, "Alex Domoradov" wrote: > > RUN