Log file Viewer
#pypa-dev logs for Tuesday the 3rd of May, 2016
[07:36:35] <ewong> currently, virtualenv.py creates the virtualenv and does the symlinking.. however, when building Thunderbird, the symlinking is overwriting the existing symlink. via https://github.com/pypa/virtualenv/blob/develop/virtualenv.py#L1355 to 1357
[07:37:32] <ewong> I'm wondering if it's logical to check whether or not the py_executable is already symlinked before symlinking the https://github.com/pypa/virtualenv/blob/develop/virtualenv.py#L1352 list to py_executable?
[18:43:34] <dstufft> njs: i'd be lying if I said I wasn't a little OK with the fact it had stalled for right now because it meant I could focus on Warehouse :] but I'm also totally willing to keep poking at it (though probably less "OMG GONNA WRITE MY OWN PEP" and more advocating for my position because PyPI is slowly dying and I'm trying to get Warehouse done enough before it does :]
[18:45:04] <njs> a lot of why I dropped the ball on following up on that conversation more quickly is that I am also struggling to figure out how to prioritize packaging-related efforts given how on fire everything is
[18:45:52] <njs> (between the pynativelib stuff, a few axes of better tooling for scientific packages, trying to figure out if I can help you get more resources, ... :-/)
[18:46:56] <dstufft> njs: prioritization wise, it might make the most sense to just punt on everything else for ABS but agreeing on a file name/format and the way we specify dependencies and ignore the "let's try and nail down a non setup.py interface part", which I think gives a lot of the benefit with far less effort and without any disagreements about how exactly to go forward with it
[18:48:07] <njs> well, let's figure out the file name/format and the way we specify dependencies and then see how much we have left :-)
[18:49:02] <dstufft> even if people don't drop setuptools, that at least allows them to use real import statements to implement stuff instead of setuptools extensions
[18:49:07] <njs> I can't tell from here how much actual debate there is about the interface part -- maybe once we sort those general strategy issues out it will turn out that it's easier to just define a new interface than it is to document the current one properly
[18:51:08] <dstufft> (woo relying on the YOLO of setup.py to paper over the hard problems while we get some wins)
[18:53:41] <dstufft> njs: I forget if I said it before, but I'm excited about the idea of pynativelib and manylinux1 has been taking off well I think