In the current README.md, the milksnake package is listed in the example setup.py's install_requires, besides the setup_requires.

I understand it being a build requirement, but why does milksnake also need to be listed as an installation requirement, ie. required at runtime by the extension module that used milksnake in its building process?

Note that I haven't used this package yet -- i'm just passing by and considering to use in my projects and too lazy to try and see what happens.

Thanks anyway!

I'd like to use this tool for a project, but the project requires Windows support. I'm curious how far out Windows support is, and what work needs to be done to support Windows.

In the readme it say "CFFI's setuptools support alone does not properly work with wheels" - but what does that exactly mean? Some examples and clarifications would help a lot.

I noticed that, when using milksnake under python3 (tested with both 3.6.3 on Linux and Windows), the fake/empty extension module that is built to trick distutils/setuptools to generate a binary wheel is still present in the generated wheel package along with the shared library built with the external build tool (e.g. cargo).

When running on python2.7, only the shared lib is present.

Is this normal or intended behaviour? I thought this empty extension module is only a temporary file that is not needed in the final distribution package. In fact, I can delete the extension module file and I am still able to import the generated cffi module.

Hi, I keep getting the following error:

error 0xc1  cannot load library 'C:\Users\a11123434\projects\venv\Lib\site-packages\xlsbconvert-0.0.1-py3.6-win32.egg\xlsbconvert\_native__lib.cp36-win32.pyd': error 0xc1

my setup.py:

from setuptools import setup

def build_native(spec):
    # build an example rust library
    build = spec.add_external_build(
        cmd=['cargo', 'build', '--release'],
        path='.'
    )

    spec.add_cffi_module(
        module_path='xlsb_csv._native',
        dylib=lambda: build.find_dylib('xlsb_csv', in_path='target/release'),
        header_filename=lambda: build.find_header('xlsb_csv.h', in_path='target'),
        rtld_flags=['NOW', 'NODELETE']
    )

setup(
    name='xlsb_csv',
    version='0.0.1',
    packages=['xlsb_csv'],
    zip_safe=False,
    platforms='any',
    setup_requires=['milksnake'],
    install_requires=['milksnake'],
    milksnake_tasks=[
        build_native
    ]
)

my cargo.toml:

[package]
name = "xlsb_csv"
version = "0.1.0"
authors = ["a random person [email protected]"]
edition = "2018"
build = "build.rs"

[lib]
name = "xlsb_csv"
path = "src/lib.rs"
crate-type=["cdylib"]

[dependencies]
calamine = "0.15.5"
csv = "1.1.1"

[build-dependencies]
cbindgen="0.9.0"

lib.rs:

#[no_mangle]
pub unsafe extern "C" fn a_test()->String{
    return String::from("abc")
}

xlsb_csv/init.py:

from xlsb_csv._native import ffi, lib

def test():
    return lib.a_test()

build.rs:

extern crate cbindgen;

use std::env;

fn main() {
    let crate_dir = env::var("CARGO_MANIFEST_DIR").unwrap();
    let mut config: cbindgen::Config = Default::default();
    config.language = cbindgen::Language::C;
    cbindgen::generate_with_config(&crate_dir, config)
      .unwrap()
      .write_to_file("target/xlsb_csv.h");
}

folder structure:

• xlsb_csv\ __init__.py
• src\lib.rs
• cargo.toml
• build.rs
• setup.py

1. The MSVC linker can't cope with undefined exported functions, compiling an extension using setuptools always assumes that the initialisation function is defined so they need to be added to empty.c
2. Add Windows DLL style in the lookup function
3. Skip rtld flag definitions (fail because they are undefined and would be ignored anyways on Windows)

seen here: https://pypi.org/project/milksnake/#description

per the internet:

As of March 16, 2018, PyPI.org aka Warehouse (finally) supports Markdown in long descriptions. Warehouse replaced the old legacy PyPI implementation in April 2018.

You need to:

 - Make sure setuptools is upgraded to version 38.6.0 or newer
 - Make sure twine is upgraded to version 1.11.0 or newer
 - Make sure wheel is upgraded to version 0.31.0 or newer
 - Add a new field named long_description_content_type to your setup() call, and set it to 'text/markdown':

setup(
    long_description="""# Markdown supported!\n\n* Cheer\n* Celebrate\n""",
    long_description_content_type='text/markdown',
    # ....
)

- Use twine to upload your distribution to PyPI.

This has also been an issue with snaek. When you install a package without wheels, installation might take a very long time (particularly when rustc is involved). The user isn't notified about that and might get the impression that the installation froze.

I attempted a patch to forward all output from the build functions (i.e. cargo's output), but it seems like this requires a lot of workarounds.

This is fix for #15 - first change is properly determine module base without loosing name parts and second is determine file name for generated cffi module using only last name component without bringing extraneous parts in case of deeply nested packages.

I have a hard time getting a callback (Python function that is registered to Rust code) to work.

Between the CFFI documentation and milksnake I find it very hard to see what I should be doing here..

https://cffi.readthedocs.io/en/latest/using.html#extern-python-new-style-callbacks lets met to think that I should actually include a extern "Python" in the cbindgen generated header or something...

In my case the rust side already exposes a signature, but of course it is not marked extern "Python"

I am getting this kind of errors because strip_directives hardcoded to True and it removed #define JIEBA_API extern

cffi.error.CDefError: cannot parse "JIEBA_API void jieba_free(jieba_t);"

Pass header_strip_directives to make_ffi so it can be disabled. (I think self. header_strip_directives was intended for this but left unused?)

Hello, The regular expression hereis no longer tolerated by the version of Python 3.11 "Global inline flags (e.g. (?i)) can now only be used at the start of the regular expressions"

Small suggested fix: _directive_re = re.compile(r'(?m)^\s*#.*?$')

The README (is there more documentation somewhere?) only has a very trivial example of how to use this, and it's not immediately clear how to do anything very complicated. For example, how would I:

1. Create a function that returns a list?
2. Define a class in Rust?
3. Write a function that takes arguments?
4. Write a function that manipulates a Python dictionary?

It is possible that these are "out of scope" for this library (which I gather is very low level), but I would find it difficult to write an interesting Python extension without doing any of these things. If it is out of scope for this library to document the idiomatic use in writing Python backends, maybe you could have a section linking to a few open source projects actually using milksnake so a new user can try to pick up the idioms?

Milksnake does not support searching for dylib/header in absolute directory.

It appends path to the in_path variable (if given): https://github.com/getsentry/milksnake/blob/ef0723e/milksnake/setuptools_ext.py#L146

This prevent setting CARGO_TARGET_DIR to an absolute path different of the rust/ subdirectory.

This PR changes the logic so that appending happens only if in_path is not an absolute path. Also, this in_path is normalized as described in #24.

Closes #24.

I had an issue with milksnake when setuping a CI pipeline for Linux, Mac and Windows.

For Windows I SET the CARGO_TARGET_DIR to a folder I can cache between runs. To prevent issue with Windows backslash being wrongly escaped (or not), I use a path similar to C:/cargo_cache/project_name/target.

After some debugging, I've realized that milksnake assumes / is used as paths separators when looking for files. See for example https://github.com/getsentry/milksnake/blob/ef0723e41df23d8f6357570c69c1e69cb31f9e9e/milksnake/setuptools_ext.py#L146

and https://github.com/getsentry/milksnake/blob/ef0723e41df23d8f6357570c69c1e69cb31f9e9e/milksnake/setuptools_ext.py#L165

Those two lines will join() the search path with the in_path argument which is split with forward slashes.

I thus end up with paths that look like C:cargo_cache/project_name/target and milksnake can't find the expected files.

It seems those lines attempt to replace the forward slashes with the platform's separator, but it's not doing a proper job.

If that is the expected behaviour, I would suggest doing something like that instead:

path = os.path.join(os.path.normalize(path), *os.path.normalize(in_path).split(os.sep))

or even just

path = os.path.join(os.path.normalize(path), os.path.normalize(in_path))

or maybe even simpler

path = os.path.normalize(os.path.join(path, in_path))