3 ms·

You can easily build a single cross-platform, cross-Python wheel that just works. You just need to add "[bdist_wheel] universal=1" to your setup.cfg and write y

by ak217 10y ago

You can easily build a single cross-platform, cross-Python wheel that just works. You just need to add "[bdist_wheel] universal=1" to your setup.cfg and write your code in a cross-Python style enabled by six and future (https://pypi.python.org/pypi/future https://pypi.python.org/pypi/future).

zzzeek 10y ago
if you have any C code, you can't. Even if your C code is optional, you shouldn't, at least one that you'd put on Pypi, because unix users with full toolchains will never see your source .tar.gz anymore from pip.
- ak217 10y ago
  Fair to say, but then there isn't any technology out there to build "a single cross-platform, cross-Python wheel that just works" and links against C code. That's true of any packaging framework that links against native code...
kevin_thibedeau 10y ago
Six is a third-party library and interferes with migration to Python 3. It requires you to tiptoe around the differences between 2 and 3. 2to3 is built in and does most of the heavy lifting for you. It should be possible to package Python code using the official Python distribution and nothing else.
- sitkack 10y ago
  2to3 only handles simple base cases, it isn't applicable for translating larger more complex codebases. The same tiptoeing you didn't want to do with six, you are doing by only using a subset of Python2 that automatically translates.
- ak217 10y ago
  > Six is a third-party library and interferes with migration to Python 3. It requires you to tiptoe around the differences between 2 and 3. That's a strange thing to say. Six and future were written to ease the migration to Python 3, and both are endorsed by the official Python porting guide (https://docs.python.org/3/howto/pyporting.html https://docs.python.org/3/howto/pyporting.html). Meanwhile 2to3 is problematic because it complicates debugging and doesn't address issues like string handling, backports and other behavioral differences. Few popular Python libraries use 2to3, and most embrace the idea of single-codebase cross-version support. I would agree that the Python core developers bungled the migration tools in the standard library, and I wish they were better. But as noted by the OP, library functionality in general is steadily becoming more decentralized, and six and future are the best options for packaging cross-version libraries today. More generally, a lot of good work has gone into the wheels architecture, and it's a huge improvement on what we had before. If you think you can come up with something better, I would encourage you to try - the opportunity is there.

by ak217 10y ago

zzzeek 10y ago

if you have any C code, you can't. Even if your C code is optional, you shouldn't, at least one that you'd put on Pypi, because unix users with full toolchains will never see your source .tar.gz anymore from pip.

ak217 10y ago
Fair to say, but then there isn't any technology out there to build "a single cross-platform, cross-Python wheel that just works" and links against C code. That's true of any packaging framework that links against native code...

kevin_thibedeau 10y ago

Six is a third-party library and interferes with migration to Python 3. It requires you to tiptoe around the differences between 2 and 3. 2to3 is built in and does most of the heavy lifting for you. It should be possible to package Python code using the official Python distribution and nothing else.

sitkack 10y ago
2to3 only handles simple base cases, it isn't applicable for translating larger more complex codebases. The same tiptoeing you didn't want to do with six, you are doing by only using a subset of Python2 that automatically translates.
ak217 10y ago
> Six is a third-party library and interferes with migration to Python 3. It requires you to tiptoe around the differences between 2 and 3. That's a strange thing to say. Six and future were written to ease the migration to Python 3, and both are endorsed by the official Python porting guide (https://docs.python.org/3/howto/pyporting.html https://docs.python.org/3/howto/pyporting.html). Meanwhile 2to3 is problematic because it complicates debugging and doesn't address issues like string handling, backports and other behavioral differences. Few popular Python libraries use 2to3, and most embrace the idea of single-codebase cross-version support. I would agree that the Python core developers bungled the migration tools in the standard library, and I wish they were better. But as noted by the OP, library functionality in general is steadily becoming more decentralized, and six and future are the best options for packaging cross-version libraries today. More generally, a lot of good work has gone into the wheels architecture, and it's a huge improvement on what we had before. If you think you can come up with something better, I would encourage you to try - the opportunity is there.