Documentation error

[juancarlospaco]

This is about https://github.com/Pebaz/nimporter/tree/nimporter-v2.0.0rc

On this image, on the right code block, at the top,
it says calculatorlib.nim but has Python code inside, I think it should be calculatorlib.py ?.

• Which versions of Python it supports ?.

[Pebaz]

Oh good catch, thanks I will update it!

[juancarlospaco]

@Pebaz
Hey the new 2.0.0 is working see here:

• https://github.com/juancarlospaco/thatlib/runs/7380391933?check_suite_focus=true
• https://github.com/juancarlospaco/thatlib/blob/nim/.github/workflows/build.yml#L68-L86

Any news of when is the merge?, right now I have to git clone to use it, because PIP installs the old one that is not really working.

🙂:+1:

[Pebaz]

@juancarlospaco Thank you very much for testing this new branch out!

I've come across one wrinkle when trying to use Nimporter v2 with faster-than-requests. The now-formalized method of distributing extension modules & libraries doesn't work with external dependencies such as DLLs (at least not that I can think of without just rote copying each file).

If you've got any ideas on how to do this in a cross-platform way while still supporting 100% C source distributions, I'd be super interested. Here's my work on faster-than-requests here: https://github.com/Pebaz/faster-than-requests

I guess it could be possible to declare external C dependencies to Nimporter or something but I haven't thought of a good way.

If that is the case though, bear in mind that this means I can't really release Nimporter v2 since bringing Nim libraries (in any form) to the Python ecosystem is part of why it exists, DLLs or not ☹. Perhaps users could just modify the extensions they get from Nimporter v2 and add flags for the DLLs? How would this work with Windows headers/OpenGL headers/etc.

It's kind of a nightmare when dealing with C source distributions as far as I can tell. Nim made it so that those things were taken care of.

Lastly, I really wanted the process of exposing a Nim library to be "non-bespoke". What I mean is "not custom every time" or at least production-ready. I was attempting to get away from custom C build systems but I think I failed lol since I can't possibly support every use case.

[juancarlospaco]

Just pack the DLLs into the package itself ?.

Thats what other packages do, or you could just mention in the docs that you need to install the DLLs, thats similar for Linux and .so files too, so I think it is Ok.
On the repo I was thinking about removing the DLL anyway.