Log file Viewer

[17:18:39] <FlyingWookie> I have a question for virtualenv on windows xp

[17:18:42] <FlyingWookie> under python 2.7.8

[17:19:01] <FlyingWookie> then I create a virtual environment env

[17:19:05] <FlyingWookie> and then activate it

[17:19:26] <FlyingWookie> then install pyserial with 'pip install pyserial'

[17:19:29] <FlyingWookie> everything is ok

[17:19:43] <FlyingWookie> and pyserial is installed under the env

[17:20:04] <FlyingWookie> then I activate it and do 'import serial' everything is ok

[17:20:22] <FlyingWookie> BUT when a python file is launched that 'import serial' it fails...

[17:21:15] <FlyingWookie> I have serached the interwebs but nothing so far... could someone suggest anythings else I could try?

[17:21:22] <FlyingWookie> *anything

[19:54:38] <agronholm> FlyingWookie: do you have multiple python installations?

[19:55:38] <agronholm> FlyingWookie: if you install pyserial in a virtualenv and then you launch a python script from outside the virtualenv, why do you expect pyserial to work then?

[20:10:55] <FlyingWookie> agronholm, no I do not have multiple python installations

[20:11:40] <FlyingWookie> I can visually see that pyserial is installed int he virtual envirnment and not the base c:\python27 install directory

[20:12:25] <FlyingWookie> one thing that I found, while searching, is to check the association on the command line with 'assoc .py'

[20:12:57] <FlyingWookie> and 'ftype Python.file'

[20:13:16] <FlyingWookie> it was pointing at the base installation for python (c:\python27)

[20:13:22] <agronholm> FlyingWookie: of course it was

[20:13:26] <FlyingWookie> agronholm, ^^

[20:13:35] <agronholm> so install pyserial in the base python installation

[20:13:47] <FlyingWookie> then I tried to install virtualenvwrapper-win

[20:14:18] <FlyingWookie> agronholm, well installing it in the base installtion defeats the purpose of using virtualenv altogether.

[20:14:20] <FlyingWookie> :(

[20:15:00] <agronholm> on the other hand, what's the point of association the virtualenv's python.exe to run all python scripts?

[20:18:46] <FlyingWookie> agronholm, true... :) I agree, but I guess that is what the installer for python does I think..

[20:19:36] <FlyingWookie> when I tried virtualenvwrapper-win to see it it associates the files correctly it did not work as well.

[20:20:05] <agronholm> how do you expect the association to work? Windows only allows a simple extension -> executable association

[20:20:38] <FlyingWookie> thank you for trying anyways agronholm .... I'm learning something new... I just did not expect to be such a pain under windows....

[20:22:03] <FlyingWookie> I do realize what that the association is in windows, it is just that there are no clear indications that when you lauch a .py file from virtualenv

[20:22:25] <FlyingWookie> it associates to the base installation c:\python27 and not your environment

[20:22:43] <nanonyme> FlyingWookie, the mapping is from system registry, not environment

[20:22:56] <FlyingWookie> since when I did launch the environment with activate and 'import serial

[20:23:01] <FlyingWookie> ' did work

[20:23:12] <FlyingWookie> nanonyme, :) I have learned that now...

[20:23:15] <nanonyme> Activating a virtualenv has no significance whatsoever to your registry

[20:23:35] <agronholm> FlyingWookie: what do you mean by launching a .py file from virtualenv?

[20:23:43] <agronholm> if this is not about the command line

[20:23:46] <nanonyme> FWIW calling them as python foo.py works as expected on Windows

[20:24:44] <nanonyme> Also if it's one of those funky packages that can be executed, things like "python -mpip install foo" are a thing

[20:25:02] <FlyingWookie> agronholm, after activating the environment, typing in foo.py

[20:25:02] <nanonyme> I actually prefer that style these days on Windows

[20:26:14] <FlyingWookie> ahh, nanonyme so if I execute/launch foo.py with python foo.py it should grap the correct python path from the activated virtualenv environment

[20:26:20] <FlyingWookie> I was missing the 'python'

[20:26:33] <FlyingWookie> 'python foo.py'

[20:26:35] <agronholm> right

[20:26:37] <FlyingWookie> instead of foo.py

[20:26:55] <nanonyme> Yup. That will pull python from PATH and work as expected. No registry lookups

[20:27:19] <FlyingWookie> agronholm, nanonyme ... sweet... I learned something today... :) thank you for the help.

[20:27:55] <FlyingWookie> It just perplexed me for a bit when after activating the environemnt and then typing in python

[20:28:06] <FlyingWookie> >>> import serial

[20:28:15] <FlyingWookie> worked in the activated environment..

[20:28:37] <nanonyme> Yes, that would as well use PATH

[20:29:52] <FlyingWookie> :) thank you again for the help

[20:31:43] <nanonyme> Incidentally, you can do stuff like put foo with a shebang in scripts and foo.cmd as well. Then *nix will run the foo with shebang and Windows foo.cmd when you call foo. You can then make those wrappers that will call python -mfoo do something

[20:32:50] <nanonyme> This assuming that the executable foo.py is platform-independent

[20:51:16] <dstufft> py.exe on Windows is supposed to allow something like that to work too

[20:51:25] <dstufft> I don't really know how it works off the top of my head tho

[21:00:45] <linovia> Is it possible to map a "virtual" package namespace over an existing one ? For example, say I have django installed and want another package to be reached through django.contrib.mypackage ?

[21:01:21] <dstufft> yes and no

[21:01:30] <dstufft> specifically for Django, no you can't

[21:01:42] <linovia> you can only do that with virtual namespace that remains virtual right ?

[21:01:52] <dstufft> but in general a package can declare itself a namespace package, and other packages can reuse that namespace

[21:02:09] <dstufft> so django could declare "django.*", and "django.contrib.*" as namespaces

[21:02:21] <dstufft> which would allow other projects to drop stuff into django.contrib.*

[21:02:27] <dstufft> but django doesn't do that

[21:03:02] <linovia> interesting

[21:03:18] <linovia> dstufft: thanks a lot

[21:03:25] <dstufft> np!

[21:04:16] <linovia> starting working on splitting raven contrib stuff into smaller packages so I'll have enough control to declare the namespace so it doesn't makes to much changes

[21:04:23] <linovia> started

[21:43:45] <linovia> I now realize that years ago I probably misunderstood the sentence: "it means that the package has no meaningful contents in its __init__.py, and that it is merely a container for modules and subpackages"

[21:44:32] <linovia> it means that __init__.py has to be dedicated to the "virtual" packaging but you can still have python files around right ?

[21:49:56] <dstufft> linovia: yes, foo/__init__.py cannot have meaningful content, but foo/wahtever.py can

[21:50:16] <linovia> nice

[22:15:54] <nanonyme> dstufft, well, py.exe is a bit orthogonal as far as I've understood

[22:16:38] <nanonyme> Ie you could have your foo.cmd *call* "py -mfoo %*" or whatever the syntax is

[22:22:27] <dstufft> yea but foo.cmd isn't as good as a .exe

[22:22:44] <dstufft> there are certain windows APIs which are hardcoded to only work with .exe's

[22:23:05] <dstufft> and afaik if you assocaite the .py extension with py.exe, then py.exe will read a shebang line just like *nix does