pmxbot IRC Log Viewer

[01:56:31] <pmxbot> jaraco pushed 4 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :

[01:56:31] <pmxbot> Include distutils in modules hidden

[01:56:31] <pmxbot> Correct docstring

[01:56:31] <pmxbot> Rename function to match intention.

[01:56:31] <pmxbot> Disable purging of distutils/setuptools during sandbox operations. Ref #315.

[01:58:13] <pmxbot> jaraco pushed 1 commit to setuptools (https://bitbucket.org/pypa/setuptools/) :

[01:58:13] <pmxbot> Merge with master

[01:58:56] <pmxbot> jaraco pushed 1 commit to setuptools (https://bitbucket.org/pypa/setuptools/) :

[01:58:56] <pmxbot> Bumped to 9.0 in preparation for next release.

[01:59:45] <pmxbot> jaraco pushed 2 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :

[01:59:45] <pmxbot> Added tag 9.0 for changeset 0d7b9b63d06a

[01:59:45] <pmxbot> Bumped to 9.1 in preparation for next release.

[04:05:14] <r1chardj0n3s> well, lol, I have RST that I can't fault, restview can't fault and yet it doesn't render on testpypi. ARGH

[04:14:17] <dstufft> r1chardj0n3s: I'm probably going to switch PyPI over to readme this week

[04:14:41] <r1chardj0n3s> so I'm thinking about ways to include rst errors in the page

[04:14:44] <dstufft> at least then the rst rendering will be isolated in it's own module that people can run locally

[04:14:45] <r1chardj0n3s> does readme do that?

[04:15:09] <dstufft> r1chardj0n3s: no, it doesn't do that, and I'm not sure we should. sounds like a good way to accidently leak information from the machine it's running on

[04:15:10] <r1chardj0n3s> (I'm avoidning reading the TUF paper and PEPs ;)

[04:15:17] <r1chardj0n3s> hm

[04:15:21] <dstufft> but since readme is an external lib

[04:15:26] <dstufft> it can do that when run locally

[04:16:08] <r1chardj0n3s> readme handles the markdown security holes?

[04:17:41] <dstufft> r1chardj0n3s: readme doesn't handle markdown at all currently (and I do't think PyPI should without a way to mark that you want markdown, the fallback thing seems like a bad idea to me), but readme can handle raw HTML safely

[04:18:08] <dstufft> it doesn't rely on the render-er to emit safe html

[04:18:12] <r1chardj0n3s> I think markdown in the face of a README.md is fine, but anything else isn't ;)

[04:18:26] <r1chardj0n3s> oh that

[04:18:34] <r1chardj0n3s> that's right, you sanitise post-render

[04:19:41] <dstufft> r1chardj0n3s: the problem is, that while PyPI can see a README.md, the metadata that PyPI makes available to everyone else via the API doesn't have a way to specify it's markdown

[04:19:59] <r1chardj0n3s> balls

[04:20:06] <r1chardj0n3s> hm

[04:20:35] <dstufft> and the fallback thing doesn't work very well, because there is a non trivial portion of markdown that also renders successfully as rst (but renders wrongly)

[04:20:51] <r1chardj0n3s> ok, I am 99.9% sure that even though I've pushed and confirmed the code push to the three web nodes they are not running the new code with the code-block fix

[04:21:11] <dstufft> so people using markdown will end up needing to use something that's not valid rst

[04:21:14] <r1chardj0n3s> yeah

[04:21:16] <dstufft> just to trick pypi into rendering markdown

[04:21:32] <dstufft> r1chardj0n3s: salt might not be smart enough to restart testpypi when a dependency changes

[04:21:37] <dstufft> instead of the code in pypi itself

[04:21:45] <dstufft> service testpypi restart

[04:21:46] <r1chardj0n3s> no, there's a code change in pypi

[04:21:48] <dstufft> oh

[04:22:01] <dstufft> I'd still probably try to restart it

[04:22:04] <dstufft> just to make sure

[04:22:09] <r1chardj0n3s> I'll try a manual restart ya

[04:23:09] <r1chardj0n3s> fixed it

[04:23:13] <r1chardj0n3s> so. salt.

[04:23:25] <dstufft> heh

[04:23:47] <r1chardj0n3s> now I'll PR that fix to production

[04:25:58] <dstufft> r1chardj0n3s: I'm also going to look at the rendering settings github uses for README.rst to and see if we can steal anything for readme too

[04:26:26] <dstufft> they have a lib similar to readme for their README.ext code

[04:26:31] <dstufft> but it's a ruby lib

[04:27:00] <r1chardj0n3s> fairnuff

[04:27:32] <dstufft> I know one thing is some code so that svg images render using the <img> tag instead of the <object> tag

[04:27:44] <r1chardj0n3s> imma give salt a chance to update prod for a bit, and go back to this horrible presentation I'm giving soon. why on Earth did I decide that talking about Python Packaging for 45 minutes would be a good idea? :)

[04:28:11] <dstufft> because docutils uses the <object> tag, but when you render svg using the <object> tag the svg gets to execute javascript (who on earth thought an image needed the ability to render javascript)

[04:28:16] <dstufft> r1chardj0n3s: ha

[04:28:29] <dstufft> r1chardj0n3s: probably for the same reason you thought writing a package index was a good idea

[04:28:30] <r1chardj0n3s> hey, svg with js is awesome ;)

[04:28:43] <r1chardj0n3s> yeah and now I get to read the TUF academic paper *again*

[04:28:55] <r1chardj0n3s> (because it is SO DULL that LITERALLY NONE OF IT STAYED IN MY BRAIN)

[04:29:01] <dstufft> r1chardj0n3s: ha, that's on my list of things to read this week too

[04:29:25] <r1chardj0n3s> and really, how did they get away with this in an academic paper "We use the term PKI to refer to contemporary PKI based on third-party CAs. Our design includes what is, in fact, a public key infrastructure. To avoid ambiguity, we will not refer to it as a PKI."

[04:29:44] <dstufft> r1chardj0n3s: if you want, I'm happy to do whatever on that PEP, I'm super opiniated about cryptography heh

[04:29:54] <dstufft> I'm going to be reading it and making sure it makes sense regardless

[04:30:00] <r1chardj0n3s> I am fully expecting you to :)

[04:30:14] <r1chardj0n3s> Imma not signing off on a PEP I don't understand tho :)

[04:30:15] <ionelmc> dstufft: https://github.com/github/markup "easy_install docutils" heheh

[04:30:28] <r1chardj0n3s> lulz

[04:30:42] <dstufft> ionelmc: what can you expect from a bunch of rubyists

[04:31:28] <dstufft> right now i'm regretting my decision to attempt to rewrite virtualenv

[04:31:52] <ionelmc> they've upset people with obscure languages when they stopped using pygments

[04:31:53] <r1chardj0n3s> geez donald, why??! :)

[04:31:58] <ionelmc> http://www.greghendershott.com/2014/11/github-dropped-pygments.html

[04:32:46] <ionelmc> dstufft: how sorry? did it got you hooked? :-)

[04:33:05] <r1chardj0n3s> wait. pygments.rb piped out to python to do the rendering!?

[04:33:06] <dstufft> r1chardj0n3s: because virtualenv is almost 100% code that is super hard to understand, full of hacks which most of them I don't think is even needed anymore, and the way it works we've got a series of bugs that any fix for one of the bugs seems to regress the other bugs so the fixes are mutually exlcusive

[04:33:13] <dstufft> r1chardj0n3s: yes

[04:33:21] <dstufft> r1chardj0n3s: so does their rst rendering

[04:33:28] <r1chardj0n3s> dstufft: yes, but surely you could just call upon the Twitters for someone else do rewrite it? :)

[04:34:00] <ionelmc> dstufft: so did you got any progress?

[04:34:21] <dstufft> r1chardj0n3s: meh, I did most of it on christmas even and I haven't touched it again till today, so 2 days in I have something that mostly works (it uses the venv module on 3.3+, and legacy hacks on < 3.3)

[04:34:24] <dstufft> eve*

[04:34:31] <r1chardj0n3s> :)

[04:34:35] <dstufft> not all of the features are working yet

[04:34:46] <dstufft> but I can create virtual environments and install stuff into them

[04:34:50] <r1chardj0n3s> nice

[04:35:06] <dstufft> I probably broke windows support and maybe support for anything that's not OSX, but that's just adding compat crap

[04:35:42] <r1chardj0n3s> meh, just leave Windows out. no-one uses that for anyhting except playing games anyway

[04:36:21] <dstufft> https://github.com/pypa/virtualenv/pull/691

[04:36:31] <r1chardj0n3s> ok, I now have 7 slides on PEP 440

[04:36:40] <r1chardj0n3s> didn't want to go into tooo much gory detail

[04:37:00] <r1chardj0n3s> (btw, grats on the PEP 440 dstufft :)

[04:37:05] <dstufft> PEP 440 is about 8000 more words than I ever thought I could write about version numbers

[04:37:12] <r1chardj0n3s> lol yeah

[04:37:53] <r1chardj0n3s> ok WHO SUBSCRIBED ME TO "INTEROPERABILITY PEPS" YOU BASTARDS

[04:38:02] <r1chardj0n3s> ;)

[04:38:16] <r1chardj0n3s> oh, nick isn't even on this channel

[04:38:22] <r1chardj0n3s> well that was wasted :P

[04:38:36] <dstufft> haha

[04:38:39] <dstufft> interopability-peps

[04:38:49] <dstufft> slowly github reigns supreme

[04:38:57] <r1chardj0n3s> nono, if you mis-type it, you have to write it on the blackboard 100 times

[04:39:22] <r1chardj0n3s> wah. Imma take my bat and ball and go home

[04:39:37] <r1chardj0n3s> wait. already am home. hm.

[04:39:55] <ionelmc> windows cannot be avoided

[04:40:14] <r1chardj0n3s> I have just loaded 2 new games I got for xmas in my windows :)

[04:40:54] <ionelmc> r1chardj0n3s: python almost works on windows

[04:41:04] <ionelmc> you should try it

[04:41:35] <ionelmc> latest virtualenv is borken on windows :-|

[04:41:47] <r1chardj0n3s> dstufft will fix that!

[04:41:48] <dstufft> ionelmc: see: why I'm rewriting things

[04:42:38] <ionelmc> dstufft: i see you're looking for a new name

[04:42:41] <r1chardj0n3s> hm, dstufft, pypi didn't restart post salt either

[04:42:45] <ionelmc> how about `realenv` ?

[04:43:02] <ionelmc> too punny? :-)

[04:43:39] <r1chardj0n3s> unless it's massively incompatible with current virtualenv, please don't change the name

[04:44:55] <dstufft> it's only a temporary rename

[04:45:05] <r1chardj0n3s> cool

[04:45:12] <r1chardj0n3s> so github random generator then

[04:45:26] <dstufft> sort of a "try this refactor of virtualenv because we changed all the things and want some testing before we bless it as virtualenv"

[04:45:31] <ionelmc> dstufft: should i try it on windows?

[04:45:33] <r1chardj0n3s> I got "flaming-shame" for my bower-to-xstatic package generator code

[04:46:03] <dstufft> ionelmc: if you want! It will probably fail since I haven't tried to do anything windows at all with it yet

[04:46:39] <ionelmc> dstufft: there's no "copy" support right?

[04:46:52] <dstufft> ionelmc: to copy one venv to a different location?

[04:47:15] <ionelmc> dstufft: windows doesn't have os.link for the older pythons

[04:47:31] <dstufft> oh you mean does it use symlinks or whatever?

[04:47:34] <r1chardj0n3s> pssh older pythons

[04:47:43] <dstufft> it's hard coded to use copying right now

[04:47:44] <r1chardj0n3s> \o/ https://pypi.python.org/pypi/spam

[04:47:45] <dstufft> not symlinks

[04:47:53] <dstufft> I'm not entirely sure it should support symlinks TBH

[04:47:54] <r1chardj0n3s> finally got that bloody fix out

[04:48:45] <dstufft> right now an empty virtualenv is 6M

[04:48:51] <dstufft> and 5.7M of that is the python binaries

[04:49:37] <r1chardj0n3s> that's unavoidable though, isn't it?

[04:50:03] <r1chardj0n3s> without some form of additional support in Python itself

[04:50:09] <dstufft> r1chardj0n3s: well symlinks would be more space efficient rather than full out copies

[04:50:20] <r1chardj0n3s> I thought Python looked up the symlink

[04:50:25] <dstufft> oh maybe it does

[04:50:27] <dstufft> I didn't try

[04:50:28] <ionelmc> they were hardlinks technically, right?

[04:51:05] <r1chardj0n3s> ionelmc: that rings a bell

[04:51:08] <ionelmc> you can't really detect a hardlink

[04:51:24] <ionelmc> since there's no owner, all the files own the inode

[04:51:31] <ionelmc> same inode

[04:51:38] <dstufft> yea

[04:51:45] <dstufft> python resolves the symlinks

[04:51:50] <dstufft> so it could be a hardlink yea

[04:52:04] <dstufft> not sure I really care about the complexity for 5.7M of saving though

[04:57:09] <ionelmc> you can always replace those copy calls with link calls later

[04:59:19] <ionelmc> dstufft: you plan to still use scripts instead of bin for windows right?

[04:59:54] <dstufft> ionelmc: whatever windows does outside of a venv

[05:00:16] <dstufft> I probably need to add a .exe or so to some things too for windows

[05:00:25] <ionelmc> dstufft: well i think you need to, otherwise you break all the stuff that assumed that the bin dir is "Scripts"

[05:00:41] <dstufft> yea sure

[05:00:44] <dstufft> I'm fine with that

[05:00:52] <dstufft> I've done roughly 0 thinking about Windows ATM

[05:01:11] <dstufft> or Linux even, though that probably mostly works since it's pretty close to OSX

[05:01:42] <dstufft> I don't think it works on 2.6 or 3.2 either right now

[05:01:50] <dstufft> though it should work on 2.7 and 3.3+

[05:02:10] <dstufft> for some defintiion of work

[05:07:32] <ionelmc> hmmm

[05:08:10] <ionelmc> dstufft: what do you plan to do about the tests? use cram or something like that?

[05:09:19] <dstufft> ionelmc: my plan is "have tests"

[05:09:27] <dstufft> I haven't figured out specifics :D

[05:09:36] <ionelmc> sooner better than later

[05:09:37] <ionelmc> :)

[05:10:31] <dstufft> yea

[05:10:32] <ionelmc> cram doesn't really run on windows tho

[05:10:39] <dstufft> I wanted to make sure it's actually possible to do what I wanted to do

[05:10:42] <ionelmc> so it might be a no-go

[05:10:43] <dstufft> before I bothered with tests

[05:11:35] <ionelmc> dstufft: any desires about test framework? like py.test or not?

[05:11:47] <dstufft> py.test is my go to framework for running tests

[05:15:48] <ionelmc> dstufft: do you accept prs for this rewrite?

[05:17:09] <dstufft> ionelmc: sure

[05:18:14] <ionelmc> dstufft: well i started one

[05:18:36] <ionelmc> looks like the builders could use some mixins for windows/posix specifics

[05:20:04] <dstufft> I'm probably done messing with it for tonight, going to work on more PEP 440 stuff instead so feel free to add stuff :)

[06:45:33] <ionelmc> File "C:\Python27\Lib\random.py", line 113, in seed

[06:45:33] <ionelmc> a = long(_hexlify(_urandom(2500)), 16)

[06:45:33] <ionelmc> WindowsError: [Error -2146893795] Provider DLL failed to initialize correctly

[06:45:39] <ionelmc> mmmmmm

[06:45:48] <ionelmc> sheer fun :-)

[06:48:38] <ionelmc> dstufft: you don't use the patched site.py in the rewrite right?

[06:49:45] <dstufft> ionelmc: I have a special site.py which does some hacks and then loads the real site.py

[06:52:24] <ionelmc> dstufft: is site.py supposed to fixup sys.path? (for the legacy builder)

[06:52:35] <dstufft> ionelmc: yes

[06:52:43] <dstufft> it does on my OSX box

[06:52:54] <dstufft> it uses a sort of dumb method though

[06:53:06] <dstufft> it might need adjusted for different slash types in windows

[06:53:13] <ionelmc> mkay, must be some bug

[06:58:39] <jezdez> dstufft: hi, mind explaining what that interop-peps repo does?

[06:59:08] <jezdez> also please to the pypa-dev list

[06:59:38] <jezdez> please don't make me read distutils-sig

[06:59:47] <dstufft> jezdez: It's just moving https://bitbucket.org/pypa/pypi-metadata-formats to github

[07:02:40] <jezdez> why the different name though?

[07:04:25] <jezdez> I still appreciate an update on the mailing list because you know there are more than you and nick :)

[07:07:30] <qwcode> and OMG, how bout just pypa/peps : )

[07:15:41] <jezdez> qwcode: revolutionary!

[07:26:05] <ionelmc> dstufft: these site.py things are really tricky

[07:26:29] <ionelmc> seems virtualenv's custom site.py had removed some of it's dependencies

[07:26:38] <ionelmc> like the traceback module

[07:32:08] <dstufft> I didn't make it or name it ;P

[07:32:26] <dstufft> I just made a team for it

[07:33:06] <dstufft> I can post to the ML though, idc

[07:34:56] <ionelmc> dstufft: ah yes, now i see the problem

[07:35:11] <ionelmc> the new site.py doesn't add the global Lib to sys.path

[07:35:18] <dstufft> it should

[07:35:40] <dstufft> it takes whatever the normal paths are, and turns them into global paths

[07:37:48] <ionelmc> dstufft: well technically it doesn't add them, it just filters them

[07:37:56] <dstufft> ionelmc: https://github.com/dstufft/virtualenv/blob/rewrite/virtualenv/builders/legacy.py#L28-L49 this part should turn the virtualenv stdlib paths into the global paths

[07:38:19] <ionelmc> but paths beginning with sys.prefix arent't in sys.path to begin with

[07:38:47] <ionelmc> dstufft: yes, that's exactly where i'm looking

[07:39:37] <dstufft> on my OSX box, what was in sys.path to start with, were paths like /path/to/virtualenv/lib/python2.7/

[07:39:50] <dstufft> and I wanted those to be /path/to/real/python/lib/python2.7/

[07:40:32] <ionelmc> aah

[07:40:35] <ionelmc> hmm

[07:41:16] <dstufft> so that the stdlib gets imported from the "real" python

[07:41:38] <dstufft> however you have to copy over anything that the site.py depends on (the shim site.py, not the real one)

[07:41:54] <dstufft> https://github.com/dstufft/virtualenv/blob/rewrite/virtualenv/builders/legacy.py#L197-L211 here

[07:41:57] <ionelmc> dstufft: i see the problem now: the cooked up sys.prefix is a relative path

[07:42:04] <ionelmc> while the stuff is sys.path is absolute

[07:42:04] <dstufft> ah

[07:42:14] <dstufft> probably need to throw a os.path.abspath() on that

[07:45:53] <ionelmc> yep

[07:47:54] <ionelmc> dstufft: the bin dir doesn't need to be on sys.path right?

[07:48:17] <dstufft> no

[07:48:26] <dstufft> "" is on sys.path sometimes though

[07:48:30] <dstufft> and that shouldn't be abspath'd

[07:50:12] <ionelmc> that is really weird

[07:50:36] <ionelmc> so i've ran .ve\Scripts\python.exe and i got .ve\Scripts in sys.path

[07:50:52] <ionelmc> before site.py runs

[07:54:07] <dstufft> maybe it's different on Windows

[07:54:24] <dstufft> what is in sys.path if you run python.exe outside of a env

[08:00:07] <ionelmc> dstufft: this is what i got

[08:00:09] <ionelmc> https://www.irccloud.com/pastebin/TdAwu53V

[08:00:27] <ionelmc> anyway, that's not really so important

[08:00:42] <ionelmc> dstufft: what's really important is this:

[08:00:52] <ionelmc> https://www.irccloud.com/pastebin/znykHwk6

[08:01:00] <ionelmc> dstufft: ring any bell?

[08:02:11] <dstufft> ionelmc: looks like it's missing something from sys.path

[08:04:46] <ionelmc> dstufft: hmmm, shouldn't those wheels be last in sys.path?

[08:05:42] <dstufft> dunno offhand

[08:08:26] <ionelmc> ok, looks like reordering sys.path doesn't do anything wrt to the .whls

[08:09:45] <dstufft> I'm pretty sure the problem is you're missing a folder off of sys.path

[08:09:48] <dstufft> not sure why though

[08:10:01] <dstufft> I'd need to pop open a windows box to play with it

[08:10:39] <ionelmc> well anyway, i'll try some more stuff

[11:24:32] <ionelmc> dstufft: found the cause

[11:24:50] <ionelmc> the subprocess runs with almost empty environ (only PYTHONPATH)

[11:25:06] <ionelmc> seems that causes the weird WindowsError: [Error -2146893795] Provider DLL failed to initialize correctly

[11:25:22] <ionelmc> there are some other variables that are required

[11:25:57] <ionelmc> probably paths to the dlls place

[11:57:51] <ionelmc> well anyway, it got it to work on windows now, heheh

[14:49:52] <pmxbot> jaraco pushed 4 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :

[14:49:52] <pmxbot> Include api_tests.txt in the sdist. Fixes #312.

[14:49:52] <pmxbot> Bumped to 9.0.1 in preparation for next release.

[14:49:52] <pmxbot> Added tag 9.0.1 for changeset fa069bf2411a

[14:49:52] <pmxbot> Bumped to 9.0.2 in preparation for next release.

[17:22:19] <ionelmc> dstufft: i have doubts about that site.py wrapping thing

[17:22:32] <dstufft> ionelmc: don't worry, I have doubts too

[17:22:33] <dstufft> :D

[17:22:57] <ionelmc> because the functionality actual path setup functionality is not in it it creates problems when you try to create a virtualenv from within a virtualenv

[17:23:20] <sigmavirus24> ionelmc: people do that?

[17:23:26] <dstufft> the virtualenv within a virtualenv has a different solution

[17:23:32] <sigmavirus24> don't do it?

[17:23:35] <dstufft> I just didn't fix that yet

[17:23:44] <dstufft> (resolve the "real" python before shelling out)

[17:23:46] <ionelmc> dstufft: lay it on me

[17:24:06] <ionelmc> yeah, that's easy, just look for sys.real_prefix

[17:24:35] <ionelmc> tho to get the actual python bin path from that is platform specific :-|

[17:25:27] <ionelmc> sigmavirus24: i'm too lazy to invent a tox that doen't use virtualenv :)

[17:25:43] <sigmavirus24> and you use tox from within a venv?

[17:25:51] <sigmavirus24> I do what dstufft does

[17:26:01] <dstufft> I only recently started doing that though

[17:26:01] <sigmavirus24> I use it on too many projects for that not to be the convenient way of handling it

[17:26:17] <dstufft> mostly because I got annoyed of creating per-projects venvs that only ever contained tox

[17:26:46] <dstufft> since 99% of the time when I want to import something and test it I use mktmpenv

[17:27:45] <dstufft> ionelmc: there are ~solutions~ to the platform specific thing, might be able to figure something out using sys.base_exec_prefix + sys.executable, or at the worst just stash the "real" sys.executable somewhere inside the virtual environment

[17:28:28] <ionelmc> dstufft: trouble i need that from the legacy virtualenv

[17:28:32] <ionelmc> not the new one

[17:28:44] <ionelmc> actually, let me show you what i'm talking about

[17:29:15] <dstufft> honestly I might just raise a RuntimeError("Sorry, delete your old ass virtualenv and create a new one") unless it's not very hard to do it

[17:29:31] <ionelmc> dstufft: so i've added some preliminary integration test: https://github.com/dstufft/virtualenv/pull/2/files#diff-7eb47fc18d4a6196f0940784484a5bf3R1

[17:29:54] <ionelmc> trouble is, that runs within tox's virtualenv

[17:30:25] <ionelmc> so i'd get a failure like this:

[17:30:26] <ionelmc> https://www.irccloud.com/pastebin/jNQQfWiQ

[17:31:28] <ionelmc> dstufft: because this code here https://github.com/pypa/virtualenv/pull/691/files#diff-6daf600e64837c3e89feaf855d0b8fc3R135 expects a non-virtualenv environment

[17:31:43] <dstufft> yea

[17:32:02] <dstufft> I didn't start on virtual environments within virtual environments yet

[17:32:07] <dstufft> so it doesn't surprise me it's broken

[17:32:28] <ionelmc> so i'm looking for a way to figure out the path to the real python.exe from within a legacy virtualenv

[17:32:41] <ionelmc> that should fix it

[17:33:44] <ionelmc> would it be reliable to do something like sys.real_prefix + 'python.exe' if windows else sys.real_prefix + 'bin/pytohn' ?

[17:35:17] <dstufft> a problem is going to be that sys.exec_prefix is the thing that we actually want to use

[17:35:26] <dstufft> but virtualenv doesn't define a sys.real_exec_prefix

[17:35:53] <dstufft> I think

[17:35:55] <dstufft> maybe not

[17:37:48] <dstufft> ionelmc: what does sysconfig.get_config_var("BINDIR") get you

[17:38:44] <dstufft> might need to be distutils.sysconfig.get_config_var("BINDIR") for 2.6 compat

[17:47:16] <ionelmc> dstufft: looks like it could work, i'm gonna use that then

[18:17:14] <pmxbot> jaraco pushed 4 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :

[18:17:14] <pmxbot> Prefer vendored packaging.

[18:17:14] <pmxbot> Bumped to 9.1 in preparation for next release.

[18:17:14] <pmxbot> Added tag 9.1 for changeset 3ed27d68d3f4

[18:17:14] <pmxbot> Bumped to 9.2 in preparation for next release.

[19:31:03] <pmxbot> jaraco pushed 5 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :

[19:31:03] <pmxbot> Remove unused import

[19:31:03] <pmxbot> Remove duplicate import

[19:31:03] <pmxbot> Rename variable for clarity.

[19:31:03] <pmxbot> Reindent using textwrap

[19:31:03] <pmxbot> Extract _patch_usage and re-implement as a context manager.

Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Monday the 29th of December, 2014