pmxbot IRC Log Viewer

[00:33:54] <wsanchez_> http://trac.calendarserver.org/changeset/13185 "Stop parsing requirements in setup.py, because dstufft says so."

[00:34:14] <dstufft> wsanchez_: \o/

[00:34:22] <wsanchez_> I have learned the "-e ."

[00:35:36] <wsanchez_> Now if I could upload C libraries to PyPI, I could nuke most of my build scripts.

[00:39:45] <dstufft> you can, just not for Linux :[

[00:40:22] <wsanchez_> Why not Linux?

[00:40:31] <wsanchez_> Or is that opening a can?

[00:44:06] <dstufft> wsanchez: So you can upload a binary Wheel, and that includes some information in the filename to determine if the wheel is binary compatible or not

[00:44:25] <dstufft> but the Wheel spec was only concerned with binary compatability with the Python interpreter

[00:44:31] <dstufft> not with other things it may be linked too

[00:45:12] <dstufft> so for example for linux, the compatibly tags for the OS itself are just basically "64bit linux"

[00:45:36] <dstufft> well a 64 bit linux RHEL 5 is vastly different binary compat from Ubuntu 14.04 or even more so Arch

[00:45:57] <wsanchez_> Ah. I think I mean that if I could shoehorn configure-based C builds into distutils…

[00:45:57] <wsanchez_> So that "pip install OpenLDAP" would build OpenLDAP in my virtualenv

[00:46:20] <dstufft> This same problem exists on OSX and Windows too, but to a much lesser extent since those generally just "work"

[00:46:58] <wsanchez_> Or something

[00:47:14] <dstufft> So we decided to have PyPI disallow Binary uploads for Linux because of the general availability fo compilers on Linux but allow it on Windows/OSX because of the lack of compilers there and the lower risk of binary incompat

[00:47:21] <dstufft> wsanchez: you can make your own Wheel server though

[00:47:36] <dstufft> all you need is like nginx exposing a directory with auto index turned on

[00:47:46] <dstufft> and just --find-links=https://example.com/my-wheels/

[00:50:08] <wsanchez_> Hrm, ok. That could even be an (HTTP) svn URL.

[00:50:08] <wsanchez_> Which is convenient

[00:51:32] <dstufft> yea, obvious warning that downloading things you're going to install over HTTP is less than ideal

[00:54:04] <wsanchez_> …right

[01:15:54] <wsanchez_> dstufft: Can you point me at your blog again? Google isn't helping me here.

[01:16:01] <dstufft> caremad.io

[01:16:18] <wsanchez_> danke

[01:16:50] <dstufft> np

[01:20:21] <wsanchez_> OK so I have some questions about the abstract/concrete thing…

[01:20:43] <dstufft> sure

[01:20:47] <wsanchez_> First, are you saying it's a bad idea to specific version number info in setup.py?

[01:21:04] <wsanchez_> ie. I usually have foo>=X

[01:21:18] <dstufft> I'm saying it's a bad idea to do foo==X

[01:21:21] <dstufft> n a setup.py

[01:21:58] <dstufft> setup.py should generally be as unrestrictive as possible given the backwards compatiblity of the dependency you're depending on

[01:22:21] <wsanchez_> So you don't think it's a good place to assert to users of your package that "this is the tested stuff we depend on"

[01:22:51] <wsanchez_> I think that's pretty fair for a library, since otherwise, you end up with possible conflicts.

[01:23:00] <wsanchez_> It's less obviously true for an application

[01:24:24] <dstufft> Yea, with most things there's grey areas here

[01:24:29] <dstufft> as with most things*

[01:24:41] <wsanchez_> Right OK.

[01:25:18] <dstufft> Generally I recommend making the setup.py as wide open as you reasoanbly can, becasue even if someone ``pip install yourapplication`` into a python with other things isntalls you can get conflicts too

[01:25:31] <wsanchez_> Second thing is I have modules that I… hrm… I just talk myself out of asking a question. :-)

[01:25:59] <wsanchez_> Sometimes phrasing the question yields an answer

[01:26:13] <dstufft> :]

[01:27:05] <wsanchez_> Oh hrm, right. If my app works with other apps I could screw you over by being too restrictive... ok

[01:33:54] <wsanchez_> Is there a way in requirements.txt to say where you can find a package without making it a requirement?

[01:34:27] <wsanchez_> ie. in setup.py I wanna say "twextpy" and in requirements.txt specify where to get it.

[01:35:02] <wsanchez_> Better example is cx_Oracle, which is optional for us, and I don't want a failure to get it to cause pip install to fail.

[01:37:13] <wsanchez_> I'm saying that dumb. I want optional stuff to stay optional: pip install "--editable=.[Oracle]"

[01:37:17] <dstufft> you can add extra indexes and findlinks in a requirements.txt

[01:37:24] <wsanchez_> ok

[01:37:35] <dstufft> pip won't read that automatically though

[01:38:02] <dstufft> e.g. if you do ``pip isntall yourthingthathasarequirements.txt`` pip won't read that requirements.txt

[01:38:15] <dstufft> this is on purpose, the end user should be in ultimate control of where they install things from

[01:38:29] <dstufft> but if they get your thing and do pip install -r requirements.txt, you can have it do all of that

[01:38:43] <wsanchez_> Yeah this is for my build script (for developers, not users or the package)

[01:53:40] <wsanchez_> Is this a valid file to point --find-links at:

[01:53:40] <wsanchez_> svn+http://svn.calendarserver.org/repository/calendarserver/twext/trunk#egg=twextpy

[01:53:47] <wsanchez_> (Just the one line)

[01:53:55] <wsanchez_> Or does it need to look like HTML?

[01:55:04] <wsanchez_> Or maybe -e links aren't allowed…?

[01:55:35] <dstufft> if you want to do -e you can just use -e in a requirements.txt

[01:56:50] <wsanchez_> But that goes make to making it not attached to an optional feature

[01:57:01] <dstufft> ah

[01:57:03] <dstufft> right

[01:57:11] <dstufft> *thinks*

[01:57:31] <dstufft> I think you can do -f svn+https://svn.calendarserver.org/.../

[01:57:39] <dstufft> -f == --find-links

[01:57:42] <dstufft> what happens if you do that?

[01:57:44] <wsanchez_> In the links file?

[01:57:56] <wsanchez_> oh

[01:58:01] <wsanchez_> ok lemme try

[01:58:37] <wsanchez_> YAY!

[01:58:44] <wsanchez_> I thought it had to be an index. Cool.

[01:59:16] <dstufft> :]

[02:05:18] <wsanchez_> OK better get home. Thanks again for the help.

[02:44:56] <jamescarr> hello

[02:45:08] <jamescarr> can someone help me understand this wheel stuff?

[02:45:08] <jamescarr> Cannot find a wheel for setuptools

[02:45:11] <jamescarr> oops

[02:47:29] <jamescarr> https://gist.github.com/jamescarr/612cf0cde03cb8f85453

[02:47:31] <jamescarr> same error tho

[02:52:43] <jamescarr> python "/usr/srv/cryptoduck/shared/virtualenv/virtualenv.py" "--distribute" "--quiet" "/usr/srv/cryptoduck/shared/virtualenv/shared"

[02:52:51] <jamescarr> why do I get this wheel horses hit?

[05:08:49] <ronny> jamescarr why the hell download virtualenv without virtualenv_support?

[05:09:38] <ronny> jamescarr: see https://github.com/pypa/virtualenv/tree/develop/virtualenv_support for what it is missing

[05:09:56] <ronny> also please use a more decent language around here

[06:20:35] <jamescarr> ronny, horses hit was decent language ;)

[06:21:00] <jamescarr> turned out capistrano-virtualenv was using 1.10 as if it was 1.9

[06:21:03] <jamescarr> had to fork and fix it

[06:32:45] <ronny> jamescarr: my brain was evil and pulled the s to the next word

[06:33:07] <ronny> so sorry ^^

[06:37:34] <jamescarr> ronny, heh, in a moment of anger I actually DID curse, but my typo saved me and kept the channel family friendly ;)

[06:37:47] <ronny> lol

[06:37:56] <ronny> i may hve to hit you with a fish later

Log file Viewer

Help | Karma | Search:

#pypa logs for Tuesday the 8th of April, 2014