xyppy
xyppy copied to clipboard
Use Setuptools build system, and Pip for install
Distributing applications via Zip archive is not reliable with current Python packaging and execution practices (relative import becomes infeasible).
The Setuptools library allows for a standard build system for Python applications, that can be managed with the standard Pip package manager.
I have implemented changes to allow Pip to read a Setuptools build system for this application. See the branch wip/feature/setuptools in my personal fork repository.
I have no problem adding pip support, but I like having a single file build option.
I've reworked the zip process to include a stub that lets me import things absolutely. Can you explain more about what you mean by this causing a problem with "current Python packaging and execution practices"?
Like I said, I can add pip support as well, but aside from that, is there a problem with an end user just carting around a xyppy.py file in the way that the zip file is being made as of these latest commits?
f12bf74128352eeea51b3d8571930297583332c5
7386843ae2dbade014d8463547ef831e1f5b9f86
I know this is an old issue but and what I'm asking here is tangential to that discussed above, but how would the build script provided be modified if there were other directories? For example, the build script now works fine if the assumption is that all files are in the xyppy
directory, as they are.
But if you wanted to scale this and have directories within xyppy
the build script would not generate a usable file because module imports would no longer resolve.
If that's not possible to do with a build script like this, that would be one major argument I could see for going the pip and build system approach, since it would let you scale the project.
That's because I'm using os.listdir instead of os.walk, so files deeper than the first layer aren't zipped up.
I did that because I occasionally had uncommitted test code in deeper folders that I didn't want added.
I just did a quick sanity check on that and using os.walk works fine for as deep a structure as you want.
Interesting. I'll have to practice with that. The problem I was having was imports into a directory was not working because it seemed that executable zips were not treating those directories as packages. But I wasn't using os.walk. It looks like when you do, you have to change up the join() a bit since using walk generates tuples. But I appreciate the insight in os.walk. I'll play around with that.
The executable zip didn't even have those directories in it, hence the error messages.
os.listdir doesn't recurse down into subfolders so nothing below the first layer was added.
But os.walk does exactly that kind of recursion.
And here's my sanity check code for reference.
Hope all this helps. Cheers.
I was just going to mention the same thing.
pip install xyppy Nothing happens.
look It is pitch black. You are likely to be eaten by a grue.
lamp on I see no lamp here.
I'll try @bignose-debian 's solution and see what happens.
merged #7 which allows for pip install from the repo.