PMXBOT Log file Viewer

server donated by Rackspace

Help | Karma | Search:

#pypa logs for Monday the 22nd of September, 2014

(Back to #pypa overview) (Back to channel listing) (Animate logs)
[17:59:48] <buck1> dstufft: i'm going to try to implement (something like) your finders idea today
[17:59:59] <dstufft> buck1: cool
[18:00:05] <dstufft> sorry I haven't gotten a chance to review anything yet
[18:00:32] <buck1> no worries, as long as you're not sitting on a "no"
[18:02:16] <buck1> i'm building on top of both the cached-properties and found-version branches
[18:02:31] <buck1> github doesn't seem to have a good workflow for pipelining PRs
[18:14:55] <buck1> dstufft: what's your day job?
[18:15:19] <dstufft> buck1: I work @ Rackspace on barbican and PyPI/pip/other-packaging stuff
[18:15:33] <buck1> oh, i noticed that slumber.in was down
[19:52:30] <buck1> does anyone know a way to remove extraneous packages from a virtualenv?
[19:57:45] <buck1> a pip equivalent to https://www.npmjs.org/doc/cli/npm-prune.html
[20:07:17] <buck1> dstufft: please to reopen: https://github.com/pypa/pip/pull/2033
[20:33:47] <zahlman> hi, I'm having some trouble with virtualenv and setuptools
[20:35:35] <zahlman> ...anyone around?
[20:43:07] <doismellburning> zahlman: yep, but I'll need more detail than that to be able to help ;)
[20:43:52] <zahlman> ok, first wanted to see if there actually was anyone. :) I'm trying to test what will happen when others install my project, by using virtualenv
[20:44:05] <zahlman> I created and activated a virtualenv, and attempt `py setup.py install`
[20:45:14] <zahlman> there are two problems: 1. the data goes to my main python installation instead of the sandbox; 2. the .egg file is copied into lib/site-packages, but no actual .py or .pyc files seem to make it (so I can't actually import the project or run the scripts)
[20:47:03] <doismellburning> zahlman: can you elaborate upon "the data goes to my main python installation" and "no actual [..] files seem to make it" please? (Ideally by gist-ing a console session showing you doing the whole lot - creation, activation, installation)
[20:48:24] <zahlman> sure thing... let me just pick the relevant parts out of my command history
[20:48:33] <zahlman> (er, terminal scrollback)
[20:48:51] <zahlman> I'm afraid you're dealing with Windows here btw ;\
[20:50:22] <zahlman> ... actually, let me start this process over in a new terminal window, it should be easier. :/
[20:50:30] <doismellburning> ideally one continuous stream of scrollback, so I can observe exactly what you did/tried/looked at
[20:52:16] <zahlman> ... ok, fine
[20:55:42] <zahlman> https://gist.github.com/zahlman/400df54b2115dfc6f362 I got rid of a couple of things, looking at other projects
[20:55:51] <zahlman> but you can see my fumbling with the commands :)
[20:56:34] <doismellburning> zahlman: what is "py"? (I suspect that is the issue, and that is not "a python from your virtualenv")
[20:56:54] <doismellburning> (though I am still reading)
[20:57:16] <zahlman> `py` is the pylauncher executable for windows
[20:58:12] <doismellburning> zahlman: does `where py` work?
[20:58:26] <doismellburning> (he says, cribbing from http://blog.pasker.net/2007/08/28/a-high-tech-entrepreneurs-guide-to-surviving-technical-due-diligence/)
[20:58:29] <doismellburning> er
[20:58:33] <doismellburning> cribbing from http://stackoverflow.com/q/304319/928098
[20:58:47] <zahlman> ... hrm. of course that doesn't know about my sandbox. python for windows doesn't install that in the python directory because of technical reasons
[20:59:06] <doismellburning> my thoughts exactly
[20:59:11] <doismellburning> I know little about Windows
[20:59:14] <zahlman> ...I didn't realize `where` works on windows o_O it's at C:\Windows\py.exe, as I expected
[20:59:26] <doismellburning> right, yep, you're not using your virtualenv's python etc.
[20:59:32] <tomprince> zahlman: It is often best to just ask your question, and then stick around for a while, and then people can answer when they get back to their computer.
[20:59:53] <doismellburning> I've never heard of pylauncher, so good luck, but this should point you in the right direction
[21:00:12] <zahlman> tomprince: normally I do this in channels that seem a little more active :)
[21:01:52] <doismellburning> zahlman: generally lurkers outnumber active users for most channels ;)
[21:01:59] <zahlman> true
[21:02:47] <zahlman> anyway, that seems to have put the files into the sandbox properly, but I still have the problem that the .egg is copied without any source files.
[21:03:39] <doismellburning> I'm afraid I know little about eggs, but would suggest pastebinning your setup.py
[21:04:21] <zahlman> I'm definitely not married to eggs. it's just what came out of setup.py install
[21:06:01] <tomprince> zahlman: It is actually more useful in channels that are less active, since the people who can answer may be in a different time zone.
[21:06:22] <tomprince> It does mean that you should close your IRC connection for at least a day or so.
[21:06:57] <doismellburning> tomprince: I assume you mean "shouldn't" ;P
[21:07:33] <tomprince> Yes, of couse.
[21:08:41] <buck1> tomprince: doismellburning: !logs
[21:08:47] <buck1> !logs
[21:08:47] <pmxbot> http://chat-logs.dcpython.org/channel/pypa
[21:09:15] <aclark> !m pmxbot
[21:09:15] <pmxbot> you're doing good work, pmxbot!
[21:09:30] <zahlman> argh... not having a fun time with the gist editor. it does not copy and paste well
[21:09:35] <buck1> dstufft: rewinding a bit: Do I have to refactor find_requirement in order to avoid these http requests? http://paste.pound-python.org/show/RwHTReR3Az70tZUt6qUh/
[21:09:59] <buck1> zahlman: uncheck the "ACE Editor" box
[21:11:36] <buck1> the first two i think you've tried to address in your recent proposal
[21:11:45] <zahlman> https://gist.github.com/zahlman/fda7edee9995d869be64 finally.
[21:11:52] <zahlman> buck1: will keep it in mind :)
[21:12:18] <doismellburning> cripes
[21:12:37] <doismellburning> that's quite a setup.py
[21:13:28] <zahlman> It's mostly so that the options can be specified in a separate file, and get some nice processing done on them
[21:13:33] <buck1> zahlman: any way we could get you to provide a minimal reproduction?
[21:14:15] <zahlman> how about if I get it to output the options dict that's ultimately used for setup(**options) :)
[21:14:35] <doismellburning> zahlman: that would help significantly!
[21:14:35] <buck1> http://sscce.org/
[21:18:42] <zahlman> so I get this sort of thing, https://gist.github.com/zahlman/d03c8f3baa10c878b468
[21:18:59] <zahlman> I didn't explicitly mention anything about eggs, I figured it's default...
[21:20:55] <aclark> What's the question?
[21:21:18] <zahlman> (you know, I don't know why I'm censoring any info, it won't be in the public release...)
[21:21:21] <buck1> zahlman: you want to use pip
[21:21:26] <buck1> pip install .
[21:21:31] <buck1> pip won't use eggs
[21:22:05] <buck1> "." being the current directory, assuming you've cd'd to it during dev
[21:22:19] <zahlman> unfortunately, pip isn't working in my virtualenv sandbox either. :(
[21:22:48] <buck1> a lovely talk https://www.destroyallsoftware.com/talks/boundaries
[21:22:56] <buck1> i'm going to see if i can't make pip look more like tihs
[21:23:01] <zahlman> I'm getting a message like `Fatal error in launcher: Unable to create process using '""C:\path\to\sandbox\Scripts\python.exe"" "C:\path\to\Scripts\pip.exe" install .'`
[21:23:09] <zahlman> note the extra double-quotes around the python path.
[21:23:32] <buck1> zahlman: windows-specific derpage
[21:23:36] <buck1> i wouldn't know =/
[21:23:36] <zahlman> clearly.
[21:23:55] <buck1> what was your exact command?
[21:24:05] <buck1> err looks like pip is an exe already
[21:24:14] <buck1> and python.exe is trying to run with it
[21:24:21] <zahlman> (sandbox) C:\path\to\bakedbeans>pip install .
[21:24:24] <buck1> probably not right
[21:25:15] <buck1> i wonder how python.exe bcame involved
[21:25:38] <zahlman> if I explicitly specify the full path to pip.exe in the sandbox, nothing changes.
[21:26:20] <buck1> word. weird.
[21:26:26] <aclark> o_O
[21:26:37] <buck1> #python might know more meb
[21:26:53] <aclark> Does #pypa even know what the question is? :-)
[21:27:13] <zahlman> aclark: I'm trying to test installing the project I'm working on into a virtualenv sandbox.
[21:27:38] <zahlman> sdist and bdist_wheel work fine, FWIW.
[21:27:47] <buck1> aclark: the above python.exe pip.exe error
[21:27:54] <buck1> he's just running pip
[21:28:38] <aclark> Oh, I see pip install . blows up
[21:28:39] <zahlman> buck1: any idea why `setup.py install` uses eggs? Is that the default?
[21:28:55] <buck1> zahlman: a relic of older days
[21:29:06] <buck1> pip is the tool now
[21:29:23] <zahlman> but I still use setup.py to package and distribute, right?
[21:29:30] <buck1> yes
[21:29:50] <aclark> !logs
[21:29:50] <pmxbot> http://chat-logs.dcpython.org/channel/pypa
[21:29:55] <buck1> setuptools was married to easy_install
[21:30:05] <buck1> it will use easy install if you tell it to install
[21:30:09] <buck1> pip replaces easy_isntall
[21:30:15] <zahlman> aha.
[21:30:59] <zahlman> anyway, in terms of distribution, the general idea is that the whole project folder (modulo .gitignore) goes on github, and the results of sdist/bdist_wheel go on PyPI, yes?
[21:31:48] <zahlman> (I'm actually entirely new to actually using tools for this, as opposed to just sending people my .py files. Rather embarrassing, really.)
[21:31:50] <buck1> yes
[21:32:17] <buck1> you can also install with git+ urls if you want to avoid pypi, generally during prototyping
[21:32:31] <aclark> zahlman: re: [20:45:14] <zahlman> there are two problems: 1. the data goes to my main python installation instead of the sandbox; 2. the .egg file is copied into lib/site-packages, but no actual .py or .pyc files seem to make it (so I can't actually import the project or run the scripts)
[21:32:53] <aclark> the answer to 1 is likely "wrong python". if you use the python from the virtualenv then that's where your package should be installed
[21:33:01] <buck1> aclark: the solution to eggs was pip, but his pip crashes
[21:33:39] <zahlman> yep. It was the wrong python because of windows stuff (the tools they give you to use 2.x and 3.x on the same machine, unfortunately have no concept of virtualenv apparently.)
[21:33:41] <aclark> and the answer to #2 is likely "broken package" meaning no packages=find_packages() or something else not configured properly
[21:34:25] <zahlman> my packages end up as ['src'], and I do have that folder with an __init__.py etc. in it
[21:34:26] <aclark> zahlman: also there is no "use of eggs", I'm not sure why py setup.py install creates an egg… does python setup.py install do the same thing?
[21:34:34] <aclark> k
[21:34:36] <aclark> hmmm
[21:35:01] <zahlman> and yes, python setup.py install did everything the same AFAICT, except into the sandbox
[21:36:11] <zahlman> by 'use of eggs' I pretty much meant 'creation of an egg', yeah
[21:36:21] <aclark> Egg or .egg-info ?
[21:36:58] <zahlman> after `python setup.py install` completes, I end up with `bakedbeans-0.0.1-py3.4.egg` in the sandbox's site-packages
[21:37:19] <zahlman> and easy-install.pth is modified
[21:37:33] <aclark> ah, weird
[21:38:01] <zahlman> the expected scripts (due to the entry_points option) also appear in the sandbox's scripts folder.
[21:38:14] <zahlman> but they don't work because the corresponding .py or .pyc folders don't appear.
[21:38:31] <aclark> What ver setuptools ?
[21:39:59] <zahlman> er, how do I check? I'm getting the package version instead.
[21:42:20] <zahlman> ... hrm. per the dist-info folders in site-packages, the sandbox appears to have 3.6, whereas the main python installation appears to have 2.1. o_O
[21:46:50] <aclark> zahlman: look in site-packages
[21:46:56] <aclark> looks like i have 3.6
[21:48:14] <zahlman> yeah, my site-packages for the sandbox claims to have 3.6.
[21:48:39] <zahlman> but... I thought virtualenv didn't download new versions of setuptools et. al.?
[21:55:21] <aclark> zahlman: well e.g. if an old setuptools was your prob you could upgrade either within the venv or outside of it or both
[21:55:56] <zahlman> but... wouldn't that require pip to work? :)
[21:56:07] <zahlman> (I mean, I guess I can take care of 'outside' at least)
[21:58:00] <aclark> pip install --upgrade setuptools should work still, even if your package is "broken"
[22:04:11] <zahlman> ok, I now have 5.8 in my main python installation. o_O
[22:04:18] <zahlman> these version numbers move really quickly1
[22:07:22] <zahlman> ... sigh.
[22:07:43] <zahlman> the usual Windows kludge seems to have done it (ensure no spaces in path)
[22:22:41] <zahlman> ok, pip is building the project fine now, although it spews out a long trace at the end because it failed to delete some temp files.