xyppy icon indicating copy to clipboard operation
xyppy copied to clipboard

Use Setuptools build system, and Pip for install

Open bignose-debian opened this issue 6 years ago • 7 comments

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.

bignose-debian avatar May 19 '18 12:05 bignose-debian

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.

bignose-debian avatar May 19 '18 12:05 bignose-debian

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

theinternetftw avatar May 24 '18 00:05 theinternetftw

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.

jeffnyman avatar May 18 '19 21:05 jeffnyman

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.

theinternetftw avatar May 19 '19 20:05 theinternetftw

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.

jeffnyman avatar May 19 '19 20:05 jeffnyman

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.

theinternetftw avatar May 19 '19 20:05 theinternetftw

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.

speters33w avatar Feb 01 '21 20:02 speters33w

merged #7 which allows for pip install from the repo.

theinternetftw avatar Jul 11 '24 20:07 theinternetftw