Hi Phil,
On Sun, 28 Feb 2021, Phil wrote:
I currently use jcc to wrap a Java library for use in Python - it works
great.
The project I'm working on is moving it's package management from
traditional pip installs to Guix:
https://guix.gnu.org/
Guix handles python packages pretty well, and I have jcc running nicely on
there.
The problem I have is that Guix expects as an input a Python source
repo, but the jcc outputs a binary wheel.
I'm not sure what you mean by "binary wheel", I'm not familiar with that
format. Yes, JCC's __main__.py documents that
--bdist generate a binary distutils-based distribution
or a setuptools-based .egg
--wheel generate wheel using setuptools (requires wheel
package: pip install wheel)
--build generate the wrapper and compile it
--compile recompile the (previously generated) module
I did not write the bdist nor the wheel support, they were contributed and I
don't now that --wheel makes a binary wheel, specifically.
Note that you have binaries in whatever you distribute, if you consider that
the JAR files or the .class files are binaries. They are required (.class
files are) for JCC to operate as it uses reflection to do its job.
I see that --build or --compile causes JCC to ask python to compile the egg
it produces. Without these flags, I think it'll just produce the .cpp files,
and with --python, the python wrappers (also C++ code).
If you don't invoke JCC with --wheel, --bdist, --build or --compile, you get
just source files (not countng .jar).
I just tried that on PyLucene (the project I originally wrote JCC for) and
no compilation happens without (some of) these flags being set.
On my Mac, with python3, the command line looks like:
$ python3 -m jcc --shared --arch x86_64
--jar <repeated many times>
--package <repeated many times> <individual classes as needed> etc...
--module <repeared a few times> --mapping ... --sequence ...
--exclude ...
--resources ...
--python lucene
--version 8.6.1
--files 10 (10 or 11 .cpp files are generated)
--> no binaries made
What I'd like is for jcc to put together a source package, complete with
jars, C/C++, and python wrapper and a setup.py that is called to
generate the wheel. But to stop short of generating the wheel for me.
I've had a look at the gnerated build directory - I could see the C/C++
source and jars, but there didn't seem to be a setup.py to trigger an install?
The installation of the python extension built by JCC is triggered by
passing --install to JCC's invocation.
Maybe what you actually want is to implement 'sdist' support for JCC ?
(again, not familiar with wheels, so I may not be making sense here).
Such a directory could be then be fed into Guix who would happily build
the package and install it using the standard setup.py provided.
As long as GUIX knows how to drive a C++ compiler and linker, build python
extensions (and knows how to build the libjcc shared library), you should
be fine.
As a crude workaround I can try to unzip the contents of the produced
wheel and stick the contents into a repo, with a new setup.py, and
MANIFEST.in file that would simply copy across the jars and the previously
build C/C++ library. However having the setup.py building the library and
installing it is a more elegant solution.
Any ideas?
Not much beyond what I just wrote, I don't understand enough about the
problem you're trying to solve nor much about current Python extension
deployment practices, I'm stuck in the days of plain setuptools.
I'm happy to integrate a patch/contribution from you if it makes sense to
me.
Andi..
