multiple candidates for rlib dependency anise found

[ChristopherRabotin]

Hi there,

My project, ANISE, is organized as a workspace and provides a Rust and a Python library, separately. I've just tried adding your stub generator, because the lack of type hinting is pretty problematic given how complex ANISE is. Here's the commit that tries this: nyx-space/anise@master...feat/type-hints .

However, when I run the stub_gen binary, I get the following error:

error[E0464]: multiple candidates for `rlib` dependency `anise` found
 --> anise-py/src/bin/stub_gen.rs:5:16
  |
5 |     let stub = anise::stub_info()?;
  |                ^^^^^
  |
  = note: candidate #1: /home/chris/Workspace/nyx-space/anise/target/debug/deps/libanise-ade813368379e110.rlib
  = note: candidate #2: /home/chris/Workspace/nyx-space/anise/target/debug/deps/libanise.rlib

I thought that maybe a cargo clean would help, but alas, the same error pops up again. Could this be due to the Cargo workspace configuration where there is an anise crate for the Rust version and anise-py for the Python version (but called anise in the pyproject.toml file)?

What other information can I give you that may help you help me debug this?

Thank you

[gtfierro]

Hey @ChristopherRabotin --- did you have any luck addressing this? I'm running into the same error on my own project. I have a separate crate for the PyO3 stuff (not the same name as the Rust crate)

[ChristopherRabotin]

I ended up rewriting the code from the Dora library to parse the Python module once it's built : https://github.com/nyx-space/anise/blob/master/anise-py/generate_stubs.py.

The issue with this approach is that only one level deep submodules are be correctly seen by IDEs (because submodules are hacked to be classes). The process is also a bit tedious : one needs to build the python library, run that script, and build the library again for the stubs to be included in the module.

[gtfierro]

Thanks so much for the quick reply! I'll see if something similar works for me.

[net]

Same issue here. I expect this will be a pretty common issue given the nature of PyO3.

@ChristopherRabotin would you consider licensing your generate_stubs.py under the MIT license?

[ChristopherRabotin]

Same issue here. I expect this will be a pretty common issue given the nature of PyO3.

@ChristopherRabotin would you consider licensing your generate_stubs.py under the MIT license?

Hey, thanks for checking on the license. I'm afraid I'm not willing to switch that file to MIT because I think any benefits to that function will be useful to many users and the MPL ensures that changes are also published under the same license. Feel free however to rework the original Apache licensed version from here: https://github.com/dora-rs/dora/pull/493/files#diff-a10a1a0973d2fdbb49952a69a1cfcc70144cab708dc015e8f03f744e5d58aae4 .

[net]

Thanks! It looks like MPL 2.0 allows for internal modification and distribution of that file without requiring public distribution anyways, which works for our case.

[ChristopherRabotin]

If modifications are made to an MPL-licensed file and those changes are distributed outside the organization, the modified file must be shared under the MPL. However, if the modified files are used and distributed internally (within the organization), there is no requirement to release those modifications publicly.