Distutils-SIG September 2017

distutils-sig@python.org

34 participants
35 discussions

by Chris Barker

On Mon, Sep 4, 2017 at 6:00 AM, Nick Coghlan <ncoghlan(a)gmail.com> wrote: > >> Do the Linux distros use pip to build their packages? > > > > Not that I am aware of. > > Fedora's build macros for Python projects currently rely on running > setup.py directly, but we've been considering switching to pip instead > since 2013 or so. PEP 517 is likely to provide the impetus to switch > from "maybe we should do that" to "we need to do that, at least if > setup.py is missing, and potentially always, so we get more consistent > installation metadata" > which is exactly why I tried to do it in conda. In a post PEP 517 world, that may be a good way to go. I'm looking forward to it. -CHB -- Christopher Barker, Ph.D. Oceanographer 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 Chris.Barker(a)noaa.gov

3 years, 5 months

string types for paths in PEP 517

by Nathaniel Smith

Hi all, Quick question about an arcane topic: currently, PEP 517 says that paths are always represented as unicode strings. For example, when the frontend calls build_wheel, it has to create a temporary dir to hold the output wheel, and it passes this in as an absolute path represented as a unicode string. In Python 3 I think this is totally fine, because the surrogate-escape system means that all paths can be represented as unicode strings, even on systems like Linux where you can have paths that are invalid according to Python's idea of the filesystem encoding. In Python 2, if I understand correctly (and I'm not super confident that I do), then there is no surrogate-escape, and it's possible to have paths that can't be represented as a unicode object. For example, if someone's home directory is /home/stéfan in UTF-8 but Python thinks that the locale is C, and a frontend tries to make a tmpdir in $HOME/.local/tmp/ and pass it to a backend then... everything blows up, I guess? So I guess this is a question for those unfortunate souls who understand these details better than me (hi Nick!): is this actually a problem, and is there anything we can/should do differently? -n -- Nathaniel J. Smith -- https://vorpus.org

3 years, 5 months

Re: [Distutils] PEP 517 again

by Chris Barker

> conda-build doesn't produce or consume wheels. It works by creating a > clean > > conda environment and running a shell script to install the python > package > > into that environment To be really clear -- conda build doesn't directly use ANY build/install system. All files produced by the install > > script are then put into a tar file, which is conda's version of a wheel. > right -- conda-build simply runs the script it is told to run (by the recipe), and then looks and sees what files were installed. In theory, one could build a conda package directly out of a binary wheel -- after all, as mentioned, they are actually pretty similar, but most folks would probably just use pip inside their conda-build recipe. In fact, that is already being done -- most python packages are built with "setup.py install", but some are built by using pip to install a wheel. But I didn't think that the goal of PEP 517 was to ensconce pip as the only way to install a package in Python. So if a build system can install (like setuptools currently does), then conda recipes may well call it directly. I don't think this really has any bearing on the the PEP, though -- As I understand it, the goal of the PEP is to formalize the interface between build systems and package managers -- and that can only be a good thing for other package managers. NOTE: For the most part, folks want to use a pip-compatible install in conda-build, because users tend to also directly use pip to install stuff in conda environments e.g. if there is not a conda package available. If a conda package were built with, say, plain distutils, then pip won't find the meta data it's looking for, and might falsely see an unresolved dependency. Personally, I've always avoided pip installing packages in conda -- preferring to make conda packages for all the deps I need, but conda-pip compatibility has come a long way, so it does work fine for many users. But it would be nice if packages didn't NEED to be pip installed -- but I think that's an issue with the wheel spec (that may well be solved). -CHB -- Christopher Barker, Ph.D. Oceanographer 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 Chris.Barker(a)noaa.gov

3 years, 5 months

PEP 541

by nassim daoud

Hello, There is a friend of mine wondering, if abandoned PyPI projects can be claimed. And if so what the procedure in order to do that. My best regards, Daoud Nassim

3 years, 5 months

why do we still put version numbers into dist-info folders

by RonnyPfannschmidt

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 map) its also not serving a purpose, as the rest of the package is unversioned at the root of site-packages. in addition all those versions in folder names, that serve no purpose, and create duplication/conflicts now creep into other peps as well, please lets take a note at setuptools - for editable installs it wont put a version in to the egg info folder and imho thats the correct way to deal with data thats not actually versioned at that level where its being stored. -- Ronny

3 years, 5 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Distutils-SIG September 2017