Re: [Cython] CLI for using Shared utility module
Hi, matus valo via cython-devel schrieb am 11.02.25 um 20:25: I am writing to you to not get lost in https://github.com/cython/cython/pull/6531. I would like to get an agreement on how we would like to proceed with a CLI. I think the tool should be part of the normal cython command, maybe: cython --share=scipy._lib.cyshared --generate-shared The question then is whether this can be combined with a normal module translation (and should still generate the shared code file) or whether it's a separate step to do the shared module generation. If it's combined, we could end up with multiple generations, even concurrently in parallel builds. This can be handled (temp file + rename) but adds complexity. Thus, the invocation above can generate the module, whereas cython --share=scipy._lib.cyshared mymodule.py would integrate it into the translation of "mymodule.py". The reason why not to use the import path is because the target package can be hidden inside a directory (e.g. src). This does not work well with the import path. The generated file should be written into the build directory. If users want to have it in a subdirectory, they'll have to specify that as build directory when invoking cython. * should utility create directories or to fail if directory does not exist? Create all necessary directories, then write the output into the target directory. No need for a failure. 2. cython parameter to instruct cython to compile module with shared utility Here, I propose to use import path and compilation directive: cython -X use_shared_utility=scipy._lib.cyshared my_module.pyx I'd rather have that as an option than a directive. "--share=fqmn" seems enough. The reason to use the import path is because the file must be internally imported in any case. The import path is a full path including the shared module. You mean the fully qualified module name, including packages, right? That seems right. Stefan ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] CLI for using Shared utility module
da-woods schrieb am 13.02.25 um 09:16: > Most people will probably want to do this from setup.py instead of > calling an executable [...] we need something that can be run from the command-line, but the main users are build systems (e.g. scikit-build/ meson) and not people. What I understood from past discussions was that build systems (specifically Meson) would rather prefer calling "cython" over a "setup.py" build. Especially for larger packages like SciPy. Thus my comments regarding the "cython" CLI interface. Programmatic "setup.py" / setuptools builds are more and more replaced by declarative build setups in the Python world. I'm therefore not sure how important "setup.py" support for this (new) feature still is. My gut feeling is that it's still relevant because C/C++ module builds tend to be non-trivial (and thus benefit from programmatic freedom), at least as soon as external native libraries are involved. Still, support in "cythonize()" seems most natural to me, given the interface of "here's a bunch of source files, now set up the extension module configuration for me". A shared library seems to fit perfectly into that approach, yielding an additional Extension config for the shared module and adapting the config of dependent modules to use it. Stefan ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
Re: [Cython] CLI for using Shared utility module
matus valo via cython-devel schrieb am 15.02.25 um 00:07: Another question popped in my mind. How we will deal with: Introduce new `cython` command parameter `--shared` which will take fully qualified module name: When we will introduce new `--shared` option we will have 3 places where we can specify shared module ffully qualified module name: 1. New Cython parameter `--shared` foo.bar 2. Cython Directive parameter: `-X use_shared_utility=foo.bar 3. Cython module comment: `# cython: use_shared_utility=foo.bar What is the priority between 1., 2. and 3.? I suppose 1. and 2. should override 3. But what we should do if 1. and 2. are set but have different values? In general, changing the code is not for everyone, passing a CLI option is easy. We should therefore prefer the CLI option over the code if both are available. Passing a different CLI option to test something out seems quick and easy, so contradictions should be fine and the CLI option should just win. Passing two options on the command line is usually resolved by letting the last one win. I think that's fine in this case as well. The "--shared" option would just set the directive, and setting the directive with "-X" would then change the directive value again (and vice versa). Stefan ___ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
