a package with is a module
If there is an answer, tutorial, readme, or docs that would help, a link would be greatly appreciated. I have finally converted my dbf library to Python3, but I want to also continue supporting at least 2.7, and I see no reason to remove the existing library which also supports back to 2.4. I've never been very happy with the egg format (cool name, but having the source zipped up is irritating when one wants to look at it) and so I have left this library as a couple modules: dbf.py, and dbf_test.py. So I have multiple problems: - how do I tell PyPI that this file is for Python2.4 - 2.6, this other file is for 2.7, and this other other file is for 3.3+ ? - if I have to stick it all in one archive, how do I tell setup.py which to install? - is it possible to have all three source files as, say, .txt files, and then have some Python code before the setup() call which renames the correct one to dbf.py? How do I know where the .txt files are at to rename them? I have skimmed http://python-packaging-user-guide.readthedocs.org/en/latest/, but didn't find what I was looking for there. Thanks for any help. -- ~Ethan~
On 27 October 2014 13:47, Ethan Furman <ethan@stoneleaf.us> wrote:
So I have multiple problems:
- how do I tell PyPI that this file is for Python2.4 - 2.6, this other file is for 2.7, and this other other file is for 3.3+ ?
- if I have to stick it all in one archive, how do I tell setup.py which to install?
- is it possible to have all three source files as, say, .txt files, and then have some Python code before the setup() call which renames the correct one to dbf.py? How do I know where the .txt files are at to rename them?
For a source distribution, you could play clever games in setup.py to put the right file in place, with the right name. But that's messy and it means that if you distribute wheels (not that there's much point in doing so) you need separate wheels for 2.6-, 2.7 and 3.3+. Alternatively, you could distribute all 3 files, as dbf \ - __init__.py - dbf_26.py - dbf_27.py - dbf_3.py Then in __init__.py do if sys.version_info[0] == 3: from .dbf_3 import * elif sys.version_info[:2] == (2, 7): from .dbf_27 import * else from .dbf_26 import * Paul
On 10/27/2014 07:04 AM, Paul Moore wrote:
On 27 October 2014 13:47, Ethan Furman <ethan@stoneleaf.us> wrote:
So I have multiple problems:
- how do I tell PyPI that this file is for Python2.4 - 2.6, this other file is for 2.7, and this other other file is for 3.3+ ?
- if I have to stick it all in one archive, how do I tell setup.py which to install?
- is it possible to have all three source files as, say, .txt files, and then have some Python code before the setup() call which renames the correct one to dbf.py? How do I know where the .txt files are at to rename them?
For a source distribution, you could play clever games in setup.py to put the right file in place, with the right name. But that's messy and it means that if you distribute wheels (not that there's much point in doing so) you need separate wheels for 2.6-, 2.7 and 3.3+.
But how? When setup.py runs, is it guaranteed to do so in a particular location relative to the installable files? And I wouldn't mind making separate wheels, if I ever get that far.
Alternatively, you could distribute all 3 files, as
dbf \ - __init__.py - dbf_26.py - dbf_27.py - dbf_3.py
Then in __init__.py do
if sys.version_info[0] == 3: from .dbf_3 import * elif sys.version_info[:2] == (2, 7): from .dbf_27 import * else from .dbf_26 import *
The problem I have with this method is that the last time I tried it setup.py attempted to pre-compile all the files, resulting in syntax errors, which makes for a lousy user experience. -- ~Ethan~
On 27 October 2014 15:07, Ethan Furman <ethan@stoneleaf.us> wrote:
For a source distribution, you could play clever games in setup.py to put the right file in place, with the right name. But that's messy and it means that if you distribute wheels (not that there's much point in doing so) you need separate wheels for 2.6-, 2.7 and 3.3+.
But how? When setup.py runs, is it guaranteed to do so in a particular location relative to the installable files?
I don't know to be honest. It's not guaranteed to be run from a particular location (you can do python /whatever/setup.py if you want) but most setup.py scripts probably assume you're in the same directory as setup.py, so it's probably always going to be there for any practical purpose. I'd do something like (untested!) here = os.path.dirname(os.path.abspath(__file__)) if sys.version_info[0] == 3: src = 'dbf_3.py' elif sys.version_info[:2] == (2, 7): src = 'dbf_27.py' else src = 'dbf_26.py' shutil.copyfile(os.path.join(here, src), os.path.join(here, 'dbf.py')) setup ( ... py_modules=['dbf'], ... )
And I wouldn't mind making separate wheels, if I ever get that far.
OK, although you'd need to be careful to get the tags right.
Alternatively, you could distribute all 3 files, as [...]
The problem I have with this method is that the last time I tried it setup.py attempted to pre-compile all the files, resulting in syntax errors, which makes for a lousy user experience.
Yeah, it's harmless but ugly. I've seen that issue myself. Paul
On 10/27/2014 08:26 AM, Paul Moore wrote:
On 27 October 2014 15:07, Ethan Furman <ethan@stoneleaf.us> wrote:
Paul Moore also declaimed:
Alternatively, you could distribute all 3 files [...]
The problem I have with this method is that the last time I tried it setup.py attempted to pre-compile all the files, resulting in syntax errors, which makes for a lousy user experience.
Yeah, it's harmless but ugly. I've seen that issue myself.
For the record, I thought setting PYTHONDONTWRITEBYTECODE from inside the setup.py script: os.environ['PYTHONDONTWRITEBYTECODE'] = True might do the trick, but - it isn't available on 2.5 - it doesn't work on 2.6 (didn't test on 2.7 nor 3.x) Oh well. Guess I'll include a note that says, "Ignore any syntax errors during 'setup.py install', they're harmless." :( -- ~Ethan~
On Oct 28, 2014, at 2:20 PM, Ethan Furman <ethan@stoneleaf.us> wrote:
On 10/27/2014 08:26 AM, Paul Moore wrote:
On 27 October 2014 15:07, Ethan Furman <ethan@stoneleaf.us> wrote:
Paul Moore also declaimed:
Alternatively, you could distribute all 3 files [...]
The problem I have with this method is that the last time I tried it setup.py attempted to pre-compile all the files, resulting in syntax errors, which makes for a lousy user experience.
Yeah, it's harmless but ugly. I've seen that issue myself.
For the record, I thought setting PYTHONDONTWRITEBYTECODE from inside the setup.py script:
os.environ['PYTHONDONTWRITEBYTECODE'] = True
might do the trick, but
- it isn't available on 2.5 - it doesn't work on 2.6 (didn't test on 2.7 nor 3.x)
Oh well. Guess I'll include a note that says, "Ignore any syntax errors during 'setup.py install', they're harmless."
:(
-- ~Ethan~ _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
I think the next version of pip might hide this unless an error in install actually occurs. I could be wrong though. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On Mon, Oct 27, 2014 at 06:47:45AM -0700, Ethan Furman wrote:
If there is an answer, tutorial, readme, or docs that would help, a link would be greatly appreciated.
I have finally converted my dbf library to Python3, but I want to also continue supporting at least 2.7, and I see no reason to remove the existing library which also supports back to 2.4.
My objgraph is a single-file Python module that supports Pythons from 2.4 to 3.4. [*] [*] Well, it _probably_ supports 2.4 and 2.5; I don't actually test that because tox no longer supports 2.4 or 2.5 (and tox dropped support for those Pythons because virtualenv dropped support for them, IIRC).
So I have multiple problems:
- how do I tell PyPI that this file is for Python2.4 - 2.6, this other file is for 2.7, and this other other file is for 3.3+ ?
Maintaining three separate files is a pain. Most people who support multiple Python versions would recommend sticking to a single source written in the common language subset. It's not that hard. http://python3porting.com/noconv.html has helpful suggestions. If you don't want to rely on the `six` module from PyPI, you can always copy the tricks it performs and do them yourself.
- if I have to stick it all in one archive, how do I tell setup.py which to install?
Even if that's possible, I don't think it's a good idea.
- is it possible to have all three source files as, say, .txt files, and then have some Python code before the setup() call which renames the correct one to dbf.py?
If you go this route I suggest copying instead of renaming.
How do I know where the .txt files are at to rename them?
Many setup.py files fail if you run them when your working directory is not the one where the setup.py resides itself. I think you can safely rely on that implementation detail. Marius Gedminas -- If the facts don't fit the theory, change the facts. -- Albert Einstein
On Mon, Oct 27, 2014 at 8:30 AM, Marius Gedminas <marius@pov.lt> wrote:
Many setup.py files fail if you run them when your working directory is not the one where the setup.py resides itself. I think you can safely rely on that implementation detail.
agreed, but if you really wanted to be sure you could use __file__ to get the path of the setup.y and go from there. -Chris -- 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@noaa.gov
participants (5)
-
Chris Barker -
Donald Stufft -
Ethan Furman -
Marius Gedminas -
Paul Moore