Log file Viewer

[14:15:46] <szx> hello

[14:16:02] <szx> how do you package a .bat file for you python script only on windows?

[14:16:58] <szx> only for windows users to be exact

[14:25:20] <ronny> szx: what for do you beedthe bat file?

[14:26:35] <szx> for easier usage

[14:28:57] <ronny> szx: to make scripts executable?

[14:29:08] <szx> yeah....

[14:29:28] <ronny> szx: if you use the console_scripts entrypoint, you will get a exe file automatically

[14:29:39] <ronny> and there is also a entrypoint for gui

[14:30:23] <ronny> szx: entrypoints are the encouraged way to get callables/scripts for your app

[14:32:01] <szx> ronny: ok, thanks!

[14:32:08] <szx> didn't know about this

[14:33:06] <ronny> szx: the ideal way for installation on windows is probably wheels

[14:33:20] <ronny> szx: combined with entrypoints of course

[14:47:49] <szx> ronny: it is possible to make it work with a script with hyphens in filename?

[14:48:18] <szx> i'm getting this error: error in x-x-x setup command: ('Invalid module name', 'x-x-x')

[14:48:58] <ronny> szx: the script name can have them, python modules obviously not

[14:50:09] <ronny> szx: its common to put the code for the commandline into something like mypkg.cli anduse my-script = pypkg.cli:main as entrypoint

[16:21:08] <The-Compiler> I'm trying to install a git-package via pip, but I see a PermissionError and then an IndexError inside pip - is this a pip bug? See http://qutebrowser.org:8010/builders/win8/builds/513/steps/unittests/logs/stdio for the full output. (it works on other platforms)

[16:23:39] <The-Compiler> (running on python 3.4)

[19:55:23] <dunpeal> Is it normal for Python in a virtualenv to "fall back" on the global stdlib if it can't find a module in the virtualenv?

[20:00:23] <carljm> dunpeal: Only if the virtualenv was created with the --system-site-packages flag.

[20:00:30] <carljm> Or created with a very old version of virtualenv.

[20:00:52] <carljm> Or you're activating the virtualenv using "activate_this.py" or something similar, instead of by running the virtualenv's python binary.

[20:02:40] <dunpeal> carljm: I'm using virtualenv-3.4 12.0.5

[20:03:21] <carljm> That version should create isolated virtualenvs by default.

[20:04:00] <carljm> The other way Python in a virtualenv could appear to fall back on system packages is if you have PYTHONPATH (or maybe PYTHONHOME?) env vars set

[20:04:47] <dunpeal> carljm: I do have PYTHONPATH, but /usr/lib isn't in it.

[20:05:25] <dunpeal> carljm: http://dpaste.com/2RDVPG6

[20:08:05] <carljm> dunpeal: to rule out shell PATH issues, run ./bin/python instead of activate and then "python"

[20:14:37] <dunpeal> carljm: http://dpaste.com/35X2FZM

[20:15:11] <dunpeal> carljm: btw, if virtualenv doesn't just copy the system Python and libs to env, where does it get them?

[20:16:27] <carljm> dunpeal: well, that's certainly interesting. no idea what might be causing that. is there a file lib/python-3.4/site-packages/no-global-site-packages.txt in the env?

[20:16:50] <carljm> dunpeal: it does a complex dance in its custom site.py to get the right paths added to sys.path

[20:17:21] <carljm> dunpeal: wait a second. I'm an idiot. cProfile is in the standard libary.

[20:17:32] <carljm> so the behavior you're seeing is entirely expected.

[20:17:53] <carljm> virtualenvs don't copy the standard library; they _always_ use the base Python's stdlib

[20:18:06] <dunpeal> carljm: why isn't cProfile import from the venv like re is?

[20:18:54] <dunpeal> imported*

[20:19:12] <carljm> dunpeal: certain stdlib modules which are needed in order to bootstrap site.py are symlinked into the virtualenv

[20:19:17] <carljm> re is one of those.

[20:19:55] <carljm> the virtualenv's python starts up and finds a key marker file within the venv, making it think that the venv's lib/python-x.x is its stdlib

[20:20:00] <carljm> then site.py runs

[20:20:10] <carljm> and adds the base Python's stdlib dir to sys.path

[20:20:30] <carljm> and (only if --system-site-packages was given when the env was created) also the base Python's site-packages dir

[20:20:31] <dunpeal> OK, now I'm confused. I thought the whole point of virtualenv was to isolate the Python executable and library from the system one?

[20:20:47] <carljm> dunpeal: no, the point of virtualenv is to isolate installed packages.

[20:21:03] <carljm> if you want to isolate _everything_, just compile Python with a custom --prefix and install it.

[20:21:27] <carljm> the point of virtualenv is to provide installed-packages isolation while not being as heavyweight as that (no need to copy entire stdlib)

[20:21:49] <dunpeal> carljm: is there a flag to copy the entire stdlib too?

[20:22:17] <carljm> no; that's not a use case virtualenv has ever intended to provide. there's no need - like I said, just install your own Python.

[20:23:12] <carljm> there really wouldn't be any difference between "virtualenv with entire stdlib copied" and "separate installation of Python"

[20:35:06] <dunpeal> carljm: thanks!

[20:40:44] <_habnabit> so if i do `pip install -r /path/to/requirements.txt`, this seems to be interpreting a requirements.txt of just `-e .` as trying to install from the cwd, not the directory containing the requirements.txt. is there a better thing to put in the requirements.txt, or should i just force the cwd of pip to be the project root?

[20:46:24] <dunpeal> wow, _habnabit is asking a question.

[20:46:29] <_habnabit> haha

[20:56:10] <carljm> _habnabit: that's too bad, "relative to requirements file" paths would be more useful. I don't know of a workaround; I always do the latter.

[20:56:19] <_habnabit> carljm, okay

[21:16:36] <tos9> _habnabit: packaging tools don't well support installation from other directories anyhow.

[21:16:46] <tos9> _habnabit: so IMO the latter.

[21:16:54] <tos9> which is highly highly unfortunate.

[21:17:26] <_habnabit> tos9, the thing is that `pip install /path/to/whatever` will still run the setup.py with the 'right' cwd

[21:18:00] <tos9> ah, does it.

[21:18:13] <tos9> didn't know that, so I just cd myself these days anyhow.

[21:18:28] <ionelmc> tos9: there was a bug with the cwd some time ago

[21:24:33] <jchen> hey, why does distribute/setuptools turn underscores in package names into `-`?

[21:24:40] <jchen> and is there a way to not have that happen?

[21:27:23] <tos9> ionelmc: what do you mean?

[21:27:40] <tos9> ionelmc: as in a case where pip wasn't properly cd'ing like _habnabit mentioned?

[21:27:52] <ionelmc> tos9: pip had a bug, that's probably where you got the wrong impression

[21:27:59] <ionelmc> it works fine now

[21:28:04] <tos9> ionelmc: oh, no I think I've encountered lots of cases, not just one particular thing.

[21:28:35] <tos9> E.g. one that comes to mind is that I think distutils (and not pip) specifically throws an error message if you pass absolute paths to scripts=.

[21:29:07] <tos9> Saying exactly "don't pass absolute paths, pass them relative to the setup.py" or something