package imports from venv

[JOJ0]

Hi again, another question:

I am packaging an app where I have 2 deps that don't exist as wheels on PyPI. I was assuming that I just install those in my packaging venv and pynsist will find them when I state them in the packages section. Is this assumption correct or did I understand or do something wrong as I am getting import errors.

When I pip-install those modules globally on my packaging machine the imports do work. Please clarify where pynsist is looking for modules.

I found this post of yours https://stackoverflow.com/questions/39842237/bundling-application-and-dependencies-with-pynsist and some more about this topic but it doesn't answer my question entirely. Also I already learned that I need to take care of all dependencies that my imported modules have themselves and include them in the "packages" list as well.

Also I wanted to mention that I very much agree with your last post here: https://github.com/takluyver/pynsist/issues/123 Automagic-dependency finding is actually an errorprone solution and gives more headache than just taking care of it entirely yourself. I like it! :-)

But also a question on this topic: I don't have to handle dependencies of modules included as wheels. Is that correct? (As I just now realize that a module I am using (dropbox sdk) throws an error on runtime that it can't import (pkg_resources))

Thanks a lot for your time!

[takluyver]

Names listed in the packages= field of the [Include] section will be looked up as Python imports, in the Python installation where Pynsist is running. So if you want it to find packages in a virtualenv, you need to install Pynsist in that env and make sure you're running it there. You can run path/to/python -m nsist in place of pynsist to be sure which Python it's running on.

Alternatively, you can put packages (unpacked, ready to import) in a folder called pynsist_pkgs next to the config file. These don't have to be listed anywhere: Pynsist will copy the whole folder and then add other packages to it.

Automagic-dependency finding is actually an errorprone solution and gives more headache than just taking care of it entirely yourself. I like it! :-)

Thanks!

I don't have to handle dependencies of modules included as wheels. Is that correct?

No, there's currently no dependency handling at all, so the pypi_wheels list needs to include all the dependencies-of-dependencies-of-dependencies as far as they go.

I possibly went a bit overboard with this. Explicitly specified package dependencies are probably much more reliable than tracing imports. But on the other hand, I quite like that this records the versions of all packages explicitly in the config file describing how your application is packaged, which should make it more consistent. Like a crude version of the lock files more modern tools offer. Perhaps we need a tool to generate this from a list of immediate dependencies - that probably hinges on the 'resolver' work currently going on in pip.

(I also started playing with a tool to identify modules loaded by a running application. It's a very rough prototype, but it's still an interesting idea I might come back to one day)

[JOJ0]

Hi, sorry for getting back so late, had quite some things to do to finish my software's packaging for windows and mac and finally release it :-) pynsist was a very very great help! thanks again for a great piece of software!

Names listed in the packages= field of the [Include] section will be looked up as Python imports, in the Python installation where Pynsist is running. So if you want it to find packages in a virtualenv, you need to install Pynsist in that env and make sure you're running it there. You can run path/to/python -m nsist in place of pynsist to be sure which Python it's running on.

That was exactly my problem. I was running pynsist.exe! After switching to python -m nsist everything was fine!

I don't have to handle dependencies of modules included as wheels. Is that correct?

No, there's currently no dependency handling at all, so the pypi_wheels list needs to include all the dependencies-of-dependencies-of-dependencies as far as they go.

Oh! Thanks for clarifying! I wasn't aware and certainly good to know!

(I also started playing with a tool to identify modules loaded by a running application. It's a very rough prototype, but it's still an interesting idea I might come back to one day)

I was having a big laugh here because of the name of the package! My native language is german and Kartoffel is probably the best name for a software package I heard in a long time! LOL! Great! How did you come up with it? I don't get the relation, or was it just for fun and not really related?

[takluyver]

I'm glad it worked for you!

Kartoffel was just a random name when I was feeling in a silly mood. :slightly_smiling_face: I'm not a native German speaker, but I learned some German at school, and I have German-speaking friends and colleagues, so the word was familiar!

[JOJ0]

I think funny name's are brilliant because easy to remember. I won't ever forget that there is a software out there called Kartoffel (let's see if I also will know what it was for in 5 years of so haha ;-)) anyway, thanks a lot for all your help and most of all for pynsist! keep on maintaining it, I don't wont to miss it for my next releases :-) this case can be closed then I think.

[takluyver]

Thanks :smiley: