Log file Viewer
#pypa-dev logs for Monday the 12th of January, 2015
[21:24:24] <xafer> sorry to nag but any clue when https://github.com/pypa/pip/pulls/xavfernandez could get some love ? :-/
[21:57:39] <jimbaker> so i'm finally adding ensurepip support to jython. i will target our patched version of pip here https://github.com/jythontools/pip. one more issue we have is that wheel support assumes an executable if sys.executable, but we need #!/usr/bin/env jython-startup-script, given that it is in fact a start up script
[21:58:24] <jimbaker> i was joking on #jython about wheel reinventing the wheel, since this was irresistible
[22:02:40] <jimbaker> hopefully we will get this pushed up at some point, but at this point, i'm going to be pragmatic and get it done
[22:27:18] <dstufft> jimbaker: I suggest not using /usr/bin/env jython-startup-script but instead using /full/path/to/startup/script
[22:28:49] <willingc> Will you be at pytn or pycon? I would love one of you explain to me how to have multiple flavors of python installed on all three major OSs
[22:35:32] <dstufft> willingc: the answer on Windows is pretty easy I think (other than PATH issues apparently), you just go and download installers from python.org and install them (for different CPython versions) and similar things for jython/pypy/etc
[22:36:43] <willingc> dstufft: but what if the end user needs anaconda for sci/data stuff and vanilla cpython for say django
[22:36:52] <dhellmann> I'm looking into a fix in setuptools, and when I run "tox" py.test spews all sorts of errors. Is https://bitbucket.org/pypa/setuptools/ the right repository for the most recent code?
[22:37:22] <dstufft> dhellmann: yes it's the correct repo, or if you're more familar with git there's a mirror at github.com/jaraco/setuptools
[22:38:24] <dhellmann> and I suppose I should ask if "tox" is even the right way to run the tests, since that isn't working in master
[22:38:36] <sigmavirus24> willingc: I'll be at PyTN and PyCon but I don't know the answer for windows, just linux and osx
[22:39:33] <dhellmann> hmm, it looks like I submitted a pull request through github once before, I'll try that repo again.
[22:40:29] <willingc> sigmavirus24: what's hard is end users/learners want something simple and even editing paths are not simple for them
[22:41:00] <sigmavirus24> willingc: so I think pyenv is rapidly becoming a very user-friendly way of doing this
[22:41:16] <sigmavirus24> And if the end user's are reformed rubyists it will be very familiar to them
[22:41:47] <willingc> sigmavirus24: yeah it gets part of the way but a few months ago was choking on anaconda and cpython coexisting
[22:42:32] <dstufft> dhellmann: I normally submit using github *shrug* jaraco would need to answer about which is preferred
[22:43:16] <dstufft> willingc: I use pyenv for OSX/Linux, but you don't get automatic security updates and you have to call pyenv init at some point in your shell boostrap process
[22:43:36] <dstufft> it could be easier, since it won't automatically upgrade 2.7.8 to 2.7.9 or anything like that :/
[22:44:28] <sigmavirus24> willingc: so I guess what we need is to sprint on something better at PyTN and PyCon =P
[22:44:50] <dstufft> willingc: as far as anaconda goes, I don't use anaconda and I'm pretty convinced that 95% of the benefit of anaconda comes from wheels and the only reason anaconda is seen as "easier" at all is because they can bootstrap the pre-built binaries themselves instead of needing to convince authors tod o it
[22:46:00] <willingc> dstufft: honestly anaconda has been easier for scientists that don't have the development/operations knowledge or time/inclination to learn
[22:46:59] <willingc> well I go to the anaconda website and I download. It puts everything (at least from a user standpoint) in one folder (Anaconda)
[22:47:46] <willingc> So the user doesn't worry about installing something that will break something else since everything is in one directory
[22:48:48] <dstufft> willingc: so on Windows that's basically the same answer except then instead of "delete the whole directory" it's "uninstall Python"
[22:48:48] <willingc> It's the workflow that they are familiar with from everything from itunes to word
[22:50:07] <dstufft> I think the same thing is true on OSX if you use the Python from the Python.org installers and it's true on OSX and Linux if you use pyenv
[22:50:19] <willingc> I wondering out loud here but is there a python tool that tells you if your installation is correct
[22:50:41] <dstufft> I can delete everything python i've installed on my OSX box by doing rm -rf ~/.pyenv
[22:52:54] <dstufft> willingc: well pyenv (and the PYthon.org) installers installl pip/setuptools by default
[22:53:00] <willingc> There are so many differing instructions floating around. Someone who programs to accomplish say a research task vs building cool tools has a hard time
[22:53:15] <jimbaker> dstufft, well on my os x laptop, this will currently result in imagemagick trying to read python scripts. which is not terribly useful, since it believes they are tiff files
[22:55:10] <jimbaker> an executable is a fine thing as well, but it makes it harder to support the wide range of systems we support, or at least people can get jython to run on
[22:56:03] <jimbaker> this is because a script - or some wrapping executable - can set things like desired heap memory, etc
[22:56:53] <jimbaker> i'm thinking it might be possible to finally resolve http://bugs.jython.org/issue1491 however since setuptools has this support
[22:57:00] <dstufft> jimbaker: Hmm? I just mean instead of making the shebang ``#!/usr/bin/env jython-startup-script`` make it ``/real/path/to/jython-startup-script``, that should be functionally equivilant right?
[22:57:58] <willingc> dstufft sigmavirus24 and others: what is the best tutorial or doc out there for installing python
[22:58:37] <jimbaker> i'm going to see if patching wheel scripts.py to use setuptools will work in this case
[22:58:44] <sigmavirus24> willingc: I'm certainly not going to say I know the best tutorial. One that we can use as a base (though) is the one on python-guide.org
[22:59:40] <dstufft> jimbaker: I think I'm super confused about what's going on because setuptools uses absolute paths too not with /usr/bin/env
[23:01:11] <jimbaker> i believe if you are on a s390 mainframe, you have to figure out the launcher however
[23:01:12] <willingc> Why don't we try this... I will try installing (2.7.9, 3.4.2, anaconda, pypy) via pyenv on osx and linux
[23:03:36] <willingc> It would be cool to see if we could simplify it to a visualization. Follow this path if you want this. Sort of like an old flow chart from when I started programming
[23:04:40] <dstufft> willingc: fwiw I'm roughly about as annoyed with anaconda as I am with most Linux Distros ;) they all break things in random ways that cause divergent installation instructios :/
[23:05:47] <tomprince> jimbaker: Is /usr/bin/env needed, though? Can't the the start-up script path be hard-coded?
[23:05:55] <willingc> dstufft: I hear you. Everyone is trying to "fix" or "solve" their own problems. It's a comedy of errors when we have 20+ newer folks to python at our weekly study group
[23:06:48] <dstufft> willingc: I hate divergence because it more or less means that people need special instructions for a variety of platforms :(
[23:07:12] <jimbaker> tomprince, no, see this email from pjenvey (now mostly on pypy) from 2008, http://bugs.jython.org/issue2250
[23:08:09] <willingc> Which makes me think more and more that a tool that can display all important configuration info about a system before install; dry run with install; and after install that is user friendly might be a very good thing
[23:08:38] <dstufft> using /usr/bin/env instead of an absolute path to the script more or less means that you'll break one of the major ways virtual environments are used
[23:09:45] <dstufft> When installing a script for "foobar" in PyPy and CPython you'll get a shebang like #!/path/to/virtualenv/bin/python
[23:10:34] <dstufft> if instead it used #!/usr/bin/env python then you'd get the wrong python if you didn't previously activate it
[23:10:50] <Arfrever> dstufft: Support for using scripts as interpreters in shebangs i specific to Linux.
[23:12:14] <dstufft> sounds like you could just as easily do something like #!/bin/sh /absolute/path/to/jython-startup-script
[23:12:23] <jimbaker> right, here's the amusing thing that happens on os x right now, https://gist.github.com/jimbaker/f1f77dfa4b53a93b2d45
[23:13:19] <dstufft> the important bit is the absolute path on the startup script, not the fact that there's not something else invoking it
[23:14:50] <jimbaker> scripts just don't work, except on linux. some workaround is required. i'm simply planning to use the one supported by setuptools
[23:15:32] <jimbaker> maybe jython 2.7.x, where x > 1, can revisit. but jython has taken *absolutely* too long to release. we cannot delay further
[23:17:13] <dstufft> jimbaker: when you say "the gist was using the absolute path", do you mean you had #!/aboslute/path/to/jython-startup-script or something like #!/bin/sh /absolute/path/to/jython-startup-script
[23:17:15] <willingc> sigmavirus24 and dstufft: thank you. I am going to start a doc repo focused initially just on install and have the weekly San Diego Python study group try to iterate it. Would love your feedback as you are able :)
[23:20:01] <dstufft> willingc: you might want to talk to Nick Coghlan too, this is sort of a different area than packaging.python.org but sort of an overlap so I don't know but I think if this turns out good it would make sense to put it someplace officialish
[23:21:21] <dstufft> lifeless: what is returned from ``ls /home/robertc/.virtualenvs/linecache2-pypy2-trusty-64/site-packages/pip-1.5.4.dist-info/``
[23:21:32] <lifeless> ls /home/robertc/.virtualenvs/linecache2-pypy2-trusty-64/site-packages/pip-1.5.4.dist-info
[23:23:17] <dstufft> basically a random debian patch to PyPy2 does something stupid (it creates __pycache__ in directories that don't have any .py files in them, which PyPy3 and CPython 3 doesn't do) which exposed a stupid bug in pip
[23:33:45] <jimbaker> (wheel scripts.py). setuptools on os x emits something like #!/usr/bin/env /Users/jbaker/jythondev/jython27/dist/bin/jython. that works
[23:34:47] <jimbaker> so i'm just going to patch the wheel support in my fork of pip, then we can figure out how to upstream as it makes sense
[23:34:50] <dstufft> jimbaker: yea that's fine then, I was just saying you don't want to use literally "#!/usr/bin/env jython-startup-script" that you want to use something that has an absolute path to the jython-startup-script, even if it's using env or sh or something to actually do the execution
[23:36:32] <dstufft> I'd probably use /bin/sh if possible and works just because it's shorter and is more likely to be in the same spot (``env`` is in different places on different OSes), the shorter thing is nice because there's a max length onh ow long a shebang line can be
[23:37:05] <dstufft> (this becomes a problem when creating virtual environments in a jenkins build sometimes since jenkins loves to nest directories and you can end up with shebangs that are too long)
[23:40:41] <dstufft> jimbaker: did you see that there's a in progress virtualenv rewrite which will use the venv module to handle isolation if the target Python has it?
[23:41:38] <dstufft> jimbaker: this should mean that Jython can implement the venv module and be in control of how the isolation works in Jython (instead of virtualenv needing to maintain different hacks for each interpreter which often times stop working because of changes in virtualenv or in the interpreter)
[23:42:31] <jimbaker> dstufft, right, the other thing is that venv should be more compatible with the very alternative ways people actually deploy jython, namely using stuff like singlejars inside war files, etc
[23:43:30] <dstufft> the rewrite _only_ uses venv for handling the actual isolation and not for the acivation scripts or installing pip and such. but it will hopefully improve the experience of using virtualenv on those platforms
[23:43:34] <jimbaker> a good thing to target for 2.7.1, which should be a relatively early release after our 2.7.0 - just the nature of thigns
[23:44:25] <jimbaker> dstufft, i assume you will be at pycon? (i'm going, giving two talks, 1) jython; 2) weakrefs)
[23:45:00] <dstufft> jimbaker: yea, the rewrite isn't done yet, andit's probably going to be released in parallel for a little while
[23:45:22] <dstufft> jimbaker: pycon is still a maybe, talking to our family lawyer about the legality of taking my step daughter into canada later this week to find out!
[23:45:30] <jimbaker> unfortunately apachecon is immediately after pycon, so it's going to be hard to attend much of the sprints
[23:45:47] <dstufft> I don't really want to take Alyssa to Canada and then come back home to the FBI deciding I'm now an international kidnapper
[23:46:16] <dstufft> (although being an international kidnapper makes me sound 1000% more hardcore than I actually am)
[23:46:23] <jimbaker> dstufft, oh interesting. i was thinking of my taking daughter, not certain if there were would be enough for her to do. on the other hand, good possible chance to work on french
[23:47:36] <dstufft> jimbaker: my duaghter has a medical condition and my wife would not handle it wel if she got sick while I was away