On Feb 5, 2014, at 9:10 PM, Daniel Holth <dholth@gmail.com> wrote:
You are probably just missing the package_dir argument to setup(), adequately documented at http://docs.python.org/2/distutils/examples.html
Pass
package_dir={'': 'src'},
to indicate that the root module starts in 'src'.
MANIFEST.in is needed. It is always a bit awkward to write.
Thank you Daniel! I will definitely take a look at that. I have to say though that this is one of the problems i have with the whole python packaging: It is scattered all over the place. I’m importing setuptools in the setup.py to build wheel while i obviously miss some information about distutils? I think it could be very beneficial to have it all moved under one umbrella project or wrapper or something like that. I as a user am interested in centralized thing that knows how to take care of everything i need in order to make a wheel. Why not to have only setup.cfg (even better wheel.cfg) that describes all necessary things including includes and package details and then have “wheel" command that knows to create it properly basing on this config? One config file, one dependencies file (requirements.txt) - one command that does the work = what the doctor ordered! No? Thanks again, Eugene
On Wed, Feb 5, 2014 at 6:41 PM, Evgeny Sazhin <eugene@sazhin.us> wrote:
On Wed, Feb 5, 2014 at 6:01 PM, Paul Moore <p.f.moore@gmail.com> wrote:
On 5 February 2014 22:20, Evgeny Sazhin <eugene@sazhin.us> wrote:
1. No python files added, neither __main__.py nor prog.py make it to the wheel, so includes are not working
The manifest is for sdists, not wheels. So includes won't "work" in the sense that you seem to be expecting. You need to specify your package details in setup.py - you don't say if you did. I suspect you're not getting a universal wheel because it looks like it isn't pure Python - maybe because it doesn't have the right files in it, I can't tell from what you're showing.
I got rid of the wheel folder as the machinery behind the wheel building (or between keyboard and chair) is not smart enough to understand how to work with packages that are one level down from the root.
my setup.py is :
setup( name="prog", version="0.1", #etc, packages=find_packages()
)
I got the wheel properly built using python setup.py bdist_wheel (i was able to do it before, but didn't realize the manifest stuff is for that way of building, not for the pip wheel). So "pip wheel" usage remains to be unclear...
You still seem to be making wheels with the intention that they are executable. I apologise if I'm reading too much into your directory structure, but if that's what you are trying to do I can well imagine that you'll get odd results as you're trying to do something the system wasn't designed for.
Paul
Yes, not only i'm making wheel executable, but i also will most probably build around the fact that it is zip-readable and therefore I will add them to the PYTHONPATH to run, just like java classpath and jar (I know - stubborn me) - that's the only thing that makes any sense! After all those arguments about C extensions and whatnot i still think that enforcing the unzipping and deploying stuff is not what packaging should provide as a solution. Plus as you see I'm trying to build universal wheel - pure python. Nobody so far could prove or at least explain why it is bad idea *for pure python*, so I think this is the way to go.
Thanks, Eugene _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig