Log file Viewer

[01:32:44] <forest> xafer: /usr/lib/python2.7/dist-packages, (some more /usr/lib/python2.7 subdirs), /home/user/.local/lib/python2.7/site-packages, /usr/local/lib/python2.7/dist-packages, (some /usr/lib/python2.7/dist-packages subdirs)

[07:10:36] <xafer> forest, well /usr/lib/python2.7/dist-packages should not be before .local ...

[07:31:22] <forest> xafer: Well, you can blame debian, ubuntu, and pip for my pythonpath. In the mean time, pip installed dependencies that it should not have, and refuses to uninstall packages that it installed. I'd say that's two problems in pip.

[07:53:01] <mgedmin> what version of pip, forest?

[07:58:32] <forest> mgedmin: 1.5.6

[07:59:08] <mgedmin> that is a bit old

[07:59:40] <mgedmin> could be a bug in pip that's been fixed upstream but never backported to ubuntu/debian?

[08:07:49] <forest> mgedmin: Good point. I'll try reproducing it with a newer version of pip, probably tomorrow.

[08:07:53] <ionelmc> mgedmin: that's like asking if the bluescreen in windows 95 was fixed in windows 10 :))

[08:08:24] <forest> ionelmc: Except that 1.5.6 is the version distributed in current ubuntu releases.

[08:08:33] <ionelmc> forest: you should definitely upgrade, 1.5 has many issues

[08:09:00] <forest> will do.

[08:09:05] <ionelmc> forest: that ain't a real reason to use it, it's like saying "i'm using windows 95 cause i don't need a license"

[08:09:46] <ionelmc> context being: windows 95 is EOL

[08:10:34] <ionelmc> maybe if i do one more win95 joke it'll be funny!

[08:12:55] <mgedmin> well, ubuntu isn't EOL, and even the latest ubuntu still ships 1.5.6 (augh!)

[08:13:07] <mgedmin> wait, seriously? xenial is on 1.5.6?

[08:13:36] <mgedmin> debian sid also

[08:15:55] <ionelmc> mgedmin: point is, 1.5.6 is EOL

[08:16:45] <mgedmin> right; bugs for pip 1.5.6 should be filed in distro bug trackers

[08:19:42] <mgedmin> apparently pip 7 is "in progress" of getting into debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786440

[08:20:01] <mgedmin> it's hard to blame Barry, he's a lot on his plate

[08:22:49] <ionelmc> mgedmin: i don't blame him, or anyone

[08:23:39] <ionelmc> mgedmin: it's just that repackaging any maintained python package is a futile endeavor - why play catch up all the time?

[08:23:59] <ionelmc> catching up is a losing game, you can't win

[08:24:16] <mgedmin> what's the alternative? not provide pip at all?

[08:24:40] <ionelmc> mgedmin: there's get-pip

[08:24:47] <ionelmc> it works well on other os

[08:25:59] <ionelmc> debian should provide it as alternative to their crapackaged pip

[08:26:33] <ionelmc> and people who don't care about their ridiculous packaging principles can use it

[08:26:46] <forest> ionelmc: I understand your point of view. It's a PITA to support old versions. Realistically, though, OS packages are a lot easier than pypi packages for admins to maintain, so OS packages usually win.

[08:26:58] <mgedmin> please don't denigrate volunteer labor even if you don't feel affinity with their goals

[08:27:39] <mgedmin> as a user, I'm glad debian packages stuff for me so I don't have to learn N unique ways of installing stuff

[08:27:53] <forest> The best solutions I've found as a developer are either to step up and be an official maintainer for debian packages, or to work closely with whomever is.

[08:29:47] <forest> From my experiences so far, debian package maintainers are very receptive to upstream developers helping them get the latest releases into the OS distributions. Someone does have to make contact, though.

[08:44:48] <ionelmc> forest: i don't really get the sysadmin argument, to me it sounds like "i'm using this worse thing, just because i don't know how to use the better other thing"

[08:49:59] <mgedmin> because there are too may things for anyone to know!

[08:50:51] <mgedmin> e.g. I still use outdated vagrant packages because I don't know how you use ruby gems to install stuff, how you upgrade it, how you keep track of security updates so you upgrade timely, etc.

[08:51:10] <mgedmin> it's not a sysadmin argument, it's a user-centric argument

[08:55:01] <ionelmc> mgedmin: spreading yourself too thin - if you're doing java, you'd use tools made in java right? if you use python, you wouldn't use tools made in java or ruby, if you can avoid it right?

[08:55:17] <mgedmin> I could avoid jenkins if I used buildbot

[08:55:26] <mgedmin> in fact I did, for many years, and now I regret all the time I wasted

[08:55:47] <ionelmc> some things you can't avoid

[08:55:51] <mgedmin> ok, I'll grant you this point -- a tool like pip is only useful if you want to dive into the python ecosystem

[08:56:13] <ionelmc> and you're paying for it

[08:57:00] <ionelmc> mgedmin: my point it: stuff you don't understand is indistinguishable from technical debt, and you should have as little of it as possible

[08:58:29] <ionelmc> mgedmin: and yeah, why would debian even provide pip if they already have a package manager?

[08:58:52] <ionelmc> it's hard not to scrutinize their decisions

[09:08:58] <ronny> moin

[10:12:17] <forest> ionelmc: It boils down to time. Almost nobody wants to spend their time screwing around with a python-specific module installer when they already have tools that manage every piece of software on their system (including python), along with automation and centralized security update notifications. Pip doesn't even come close to replacing the tools that have to be used anyway, so it really only makes sense for people actively developing python code or

[10:12:18] <forest> running something that requires the very latest version of some dependency. For everyone else, it's a waste of time. Even more so for sysadmins, because they often manage dozens, hundreds, or thousands of machines, and pip simply cannot compare to the debian tools at scale.

[10:15:43] <forest> ionelmc: Your comments/questions about what debian provides hints that you might not understand how the debian software archive works. Most of the stuff in the archive is there because someone wanted it enough to roll up their sleeves and package it, or else convince someone to do it for them. When something isn't up to date, it's often because the original maintainer moved on, or got busy, or died, simply isn't aware that there's a new version.

[10:16:06] <ionelmc> forest: i don't disagree, i'm only saying a developer-centric approach should be allowed too, or at least be supported as first-class

[10:20:37] <ionelmc> i should prolly argue this with debian's maintainers

[10:21:43] <forest> I get a tremendous amount of value from debian packages, and I feel a little bit of privilege when some of my code gets published in the largest (and arguably the most important) software repository in the world. It gives my code more exposure, and my code then helps more people that it ever would otherwise. That's part of why try to work with debian maintainers on getting the latest updates into the archive. It's not that hard to do, and the

[10:21:44] <forest> benefits to the community are significant.

[10:22:31] <forest> Anyway, it's past my bed time. Goodnight, all. :)

[12:22:15] <hetii> Hi

[12:22:21] <hetii> any clue: http://www.pastebin.ca/3330614

[12:23:59] <hetii> ok works by: pip install git+git://github.com/kontron/python-ipmi.git

[13:25:01] <grepwood> hi everyone

[13:25:27] <grepwood> I'm behind a proxy, and pip can't seem to get the proxy argument to work

[13:26:03] <grepwood> I do `pip --proxy ip.address:port search messytables` and all I get is a 10 minute wait before it finally tells me I wasted me time :(

[13:26:22] <grepwood> can someone please tell me how do I properly use pip from behind a proxy?

[13:51:29] <mgedmin> grepwood, set the https_proxy environment variable (note the s)

[13:51:50] <mgedmin> also, if I were you I'd file a pip bug because why even have a --proxy argument if it does nothing?

[21:16:30] <aviau> Hey guys! I'm hacking on a setup.py and I was wondering how do console_scripts knows when to install in /usr/bin or /usr/local/bin

[21:17:05] <aviau> I'm trying to reproduce a similar behaviour in something custom.

[21:17:23] <aviau> Looks like sys.prefix is /usr, so my script installs in /usr/bin :(

[21:28:54] <ronny> aviau: that logic is somewhere in setuptools#

[21:46:13] <aviau> ronny: Thanks, I'm looking for it

[22:05:12] <ronny> aviau: what are you building?

[22:06:09] <ronny> a general good suggestion these days is, dont build installers, generate wheels and use pip as installer

[22:20:35] <aviau> ronny: I am using pbr and I'd like to install a symlink to share/something in usr/local/bin

[22:20:56] <aviau> I'm using a setup-hook for this

[22:21:47] <aviau> pbr works well with data files. They are installed in usr/local at the proper times