PEP 376 added a file to the .dist-info directory called "INSTALLER" which was
supposed to be:
This option is the name of the tool used to invoke the installation.
However, nothing has really ever implemented it and it's gone largely ignored
until just recently pip 8.0 started writing the INSTALLER file into the
metadata directories with a value of "pip".
I'd like to propose adding a special cased value to add to the installer file
that will tell projects like pip that this particular installed thing is being
managed by someone else, and we should keep our hands off of it. According to
PEP 376 the supported values for this file are r"[a-z0-9_-.]", however I think
since nobody has ever implemented it, we could expand that so that it so you
can also have a special value, of "dpkg (system)" or maybe that's not worth it
and we could just have "system" as a special value.
The benefit of doing this, is that with a special value in that file that says
"this file belongs to the OS", then pip could start looking for that file and
require a --force flag before it modifies any files belonging to that project.
Then distributors like Debian, Fedora, etc could simply write out the INSTALLER
file with the correct value, and pip would start to respect their files by
Thoughts? Does this sound reasonable to everyone? Do we think it needs a new
PEP or can we just amend PEP 376 to add this extra bit of information?
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
> On Thu, Jan 21, 2016 at 11:55 AM, Robert T. McGibbon <rmcgibbo(a)gmail.com>
>> > These are all X11, yes? pretty much any workstation will have these,
>> but in general, servers won't.
>> > Someone on this thread suggested that that's OK -- don't expect a GUI
>> package to work on a linux box without a GUI. But some of these libs might
>> get used for stuff like back-end rendering, etc, so would be expected to
>> work on a headless box. I think Anaconda an Canopy have gotten away with
>> this because both of their user bases are primarily desktop data analysis
>> type of stuff -- not web services, web servers, etc.
>> I can only speak for myself and my team, but we use Anaconda on servers
>> on a daily basis, including with libraries like matplotlib to generate
>> images that are displayed over a web service.
>> I believe this is a pretty common use case, especially with popular apps
>> like Jupyter servers.
> yup -- and Bokeh -- getting more popular -- do you put X11 on your servers?
Christopher Barker, Ph.D.
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Pip refers to PEP 440 when defining the format of a requirement (see
But PEP 508 *also* defines a requirement - the title implies that it's
for dependency specification, but the content of the PEP says "the
language defined is a compact line based format which is already in
widespread use in pip requirements files".
So what's the relationship between PEP 440 and PEP 508? Which one is
the definitive definition of what is a "requirement"? The "packaging"
library implements specifiers which conform (according to the docs) to
IMO, we're in danger of switching from having too few standards to
having too many...
Can someone clarify?
Just wanted give distutils-sig a heads-up that there seems to be some
momentum gathering around a plot to bring linux wheels to pypi:
Basically the idea is to define a standard baseline linux environment
(available libraries + version numbers + ABI of these), give it a name
(for now, "manylinux"), and then provide tools to build wheels against
this environment, teach pip how to recognize that the system it's on
conforms to the environment, and then convince pypi to start accepting
wheels with this as a platform tag :-). And if we carefully define the
baseline environment based on the experiences of the popular
scientific python distros (Continuum's Anaconda + Enthought's Canopy)
we can be highly confident that essentially all desktop + server linux
distros will be compatible with these wheels.
This strategy is orthogonal to the more ambitious efforts to define an
interface between wheels and the platform package manager; they can
proceed in parallel and potentially complement each other. The goal
here is just to get linux up to feature parity with windows and osx.
- we have a draft policy
- there's a cool tool for scanning wheels and checking whether they
conform to the policy: https://github.com/manylinux/auditwheel
- there's a draft docker image to make it easy to build such wheels
- bikeshed the name ("manylinux" was picked after about 2 minutes of
discussion so as to get started. maybe "genericlinux" would be better?
- build some test wheels
- write a proper PEP
- convince pip and pypi maintainers that this is a good idea ;-)
Nathaniel J. Smith -- http://vorpus.org
Hi, Is data_files deprecated ? I use it to install files to a known location. I had a look at some of the tickets and am still not 100% sure.
package_data won't really work, as the location isn't know.
(I have the package 'vext' which can find the files installed by vext.gi vext.pygtk etc) S++
The language-check (https://pypi.python.org/pypi/language-check)library has
the dependency of '*3to2*' in *python 2.7*,
In a virtualenv it works fine with pip,that is
*pip install 3to2*
*pip install language-check*
But its failing with easy_install in venv
*easy_install language-check* (It fails)
Due to this I'm not able to build my project using *setuptools*.
Hello I'm having trouble understanding the right way to build a c++
module using setuptools. I've been reading the docs, but I'm confused
where I should be putting my build options. Everything builds fine on
its own. I have my sources in src/ and my headers in include/.
My first problem is that I'm having trouble figuring out where to put my
build flags. Here is the Makefile I'm currently using:
ccflags=-std=c++11 -g -O3 -fPIC
includes=-I. -I./include/ -I/usr/include/python2.7/ -I/usr/include/boost
ldflags= -shared -Wl,--export-dynamic
$(cc) $(libflags) $(ldflags) $(objs) -o patent_computer_cpp.so
$(cc) $(ccflags) $(includes) -c -o $@ $<
Unfortunately I can't post the sources, but they compile fine to produce
the `patent_computer_cpp.so` file which can be imported as a module.
Maybe I should also point out that I'm using boost-python (I don't think
this is the issue though).
I just can't figure out how to get setuptools.Extension to use these
build flags. I've seen recommendations online saying that I should set
CFLAGS as an environment variable and set OPT='' as an environment
variable as well, but this just feels wrong given the simplicity of my
setup. (Besides the shared object doesn't seem to compile correctly in
this case.) I've tried using the extra_compile_args option in setup.py,
but that fails.
Is there a way to avoid setting environment variables like this or is
this the accepted way to build this kind of software? Am I missing some
obvious docs somewhere? Thanks for any help.