pmxbot IRC Log Viewer

[11:39:23] <wirrbel> dstufft, I read you are looking for pypi localization

[11:40:01] <wirrbel> I cannot point you to someone with experience in localization, but I would like to add some experience as a non english native dev

[11:41:19] <dstufft> wirrbel: Right now, we're trying to figure out the toolchain for doing so in Warehouse (what will become PyPI in the near future). The issue is https://github.com/pypa/warehouse/issues/881

[11:42:27] <wirrbel> localizing development resources (apart from introductory texts/books) is not something that I look for, and I have yet to meet someone who longs for localized docs/ pages.

[11:43:12] <wirrbel> so when it comes to prioritizing scarce development resources, this might be good to know

[11:43:20] <wirrbel> of course that is only my opinion

[11:43:32] <wirrbel> ;)

[11:43:38] <wirrbel> appreciate all your work with python packaging

[11:44:31] <wirrbel> regarding issue 881, I unfortunately don't have too much experience for recommending sth.

[11:44:33] <dstufft> thanks :)

[11:45:03] <dstufft> gotta run to take my daughter to the bus stop

[11:45:24] <wirrbel> also, if you localize pages and detect the browser's preferred locale, please make it configurable in the login/profile of a user

[11:45:45] <wirrbel> so I can opt for english dev docs

[11:45:58] <wirrbel> while keeping other pages in my native language

[11:45:58] <wirrbel> alright

[11:45:59] <wirrbel> take car

[11:46:01] <wirrbel> e

[12:10:38] <noregret> is there somethign wrong with pip ? https://bpaste.net/show/7e6b1a06be19 - i can browse to pypi.python.org normally

[12:46:40] <ionelmc> noregret: do you use a proxy or something

[13:13:04] <noregret> ionelmc: yes i think so, i see it under automatic config script in IEs options

[13:14:34] <noregret> ionelmc: is there a way to run pip without going thru the proxy? coz as i said, i can browser that address normally in firefox

[13:15:26] <ionelmc> noregret: you might need to manually specify the proxy

[13:15:40] <mgedmin> I think the problem is exactly the opposite: pip doesn't know about the proxy, and direct https access is forbidden by the firewall

[13:17:15] <mgedmin> try setting the https_proxy environment variable

[13:31:01] <noregret> mgedmin: yeah, as soon as I figure out the proxy address

[13:32:00] <noregret> can i use domain\username in pip --proxy ?

[13:33:47] <mgedmin> I've never used a proxy on Windows (or anywhere else), but Google tells me the format is ... http://stackoverflow.com/a/14150397

[13:46:47] <aviau> Hey guys! I am having troubles with pbr. I have a git submodule in my project and its breaking my install.

[13:46:54] <aviau> error: can't copy 'mailpile/contrib/print': doesn't exist or not a regular file

[13:47:31] <aviau> 'print' is the submodule. It looks like it has to do with setuptools-git or something, and probably the content of the folder is ignored

[13:47:54] <aviau> Its included in my MANIFEST.in file, and that didn't help.

[13:47:59] <mgedmin> does it exist?

[13:48:18] <mgedmin> did you run 'git submodule update --init' or whatever the magic git command to make submodules actually appear is?

[13:49:19] <aviau> Yeah the folder is here and it has stuff in it

[13:49:27] <aviau> renaming it to potato will fix the issue.

[13:49:37] <aviau> I think it has to do with git ls-files

[13:49:51] <aviau> that is called by setuptools, and that does not include submodules files

[13:49:51] <mgedmin> could be that pbr just doesn't support git submodules

[13:50:08] <mgedmin> or whatever setuptools plugin that actually ends up being used?

[13:51:41] <aviau> Thats what im trying to figure out

[13:51:48] <aviau> There is a bug somewhere...

[13:52:01] <aviau> The issue here is that its trying to copy a file as if it were a folder

[13:52:30] <mgedmin> or maybe the other way around

[13:52:44] <aviau> indeed

[13:52:50] <aviau> my bad lol

[13:54:12] <mgedmin> no bugs mention submodules at https://bugs.launchpad.net/pbr

[13:55:17] <mgedmin> two commit messages mention submodules, but they target a different usecase

[13:55:27] <mgedmin> my suggestion: file a bug, see what happens

[14:00:42] <aviau> mgedmin: done https://bugs.launchpad.net/pbr/+bug/1530867

[14:03:38] <mgedmin> for the record here's what I had to do to support git submodules in check-manifest:

[14:03:39] <mgedmin> https://github.com/mgedmin/check-manifest/commit/effec6c72e91a3ee4812a4f6e9e554ebb6a89e28

[14:04:05] <mgedmin> (and it made my test suite run for 1h45m on windows because 'git submodule foreach' is AMAZINGLY slow on Windows)

[14:04:33] <ronny> hmm

[14:05:09] <ronny> by now im aware of at least 9 different scm abstraction libs in python

[14:08:59] <noregret> i'm trying the following, https://bpaste.net/show/65e81585cab4 - it looks like it's not reading the creds, is the syntax wrong?

[14:12:30] <mgedmin> hmm :/

[14:12:47] <mgedmin> maybe it needs to be all-lowercase?

[14:13:03] <mgedmin> but envvars on windows are case-insensitive, aren't they?

[14:13:13] <mgedmin> sorry, I've no experience with this

[14:13:44] <mgedmin> I can keep googling stackoverflow for you, but that doesn't seem like a productive use of my time

[14:21:23] <noregret> mgedmin: lol yeah sure, thanks

[14:32:37] <aviau> ohh I think I get it

[14:32:43] <aviau> git ls-files returns contrib/print

[14:32:46] <aviau> even tough its not a file

[14:32:58] <aviau> its a folder

[14:33:26] <aviau> https://github.com/openstack-dev/pbr/blob/master/pbr/git.py#L108

[15:29:51] <aviau> mgedmin: Thanks for helping me think, I opened a Pr here: https://review.openstack.org/#/c/263297/

[17:44:41] <buck1> how come the newest version of virtualenv (13.1.2) ships a wheel package that's two versions old? (0.24.0 < 0.26.0) ?

[17:51:19] <ionelmc> buck1: are you asking why virtualenv is practically unmaintained? :)

[17:52:13] <buck1> i was wondering if there was a reason at all

[17:52:39] <dstufft> that was the latest version of wheel when 13.1.2 was released

[17:52:46] <buck1> i see

[17:52:55] <buck1> is it sufficient reason to bump virtualenv?

[17:53:23] <dstufft> I plan to cut a pip release soon, and we always release virtualenv at the same time as that as well, so probably not ATM

[17:53:39] <dstufft> I might go add the thing to virtualenv that'll have it pull the latest versions from PyPI too.

[17:53:56] <buck1> virtualenv --update?

[17:54:19] <dstufft> not 100% sure what exactly it'd look like

[17:54:36] <ionelmc> no one expects virtualenv to need network access no?

[17:54:47] <buck1> it's the current contract: no networking required

[17:54:49] <dstufft> it used to

[17:54:57] <buck1> but progressively enhanced by networking? maybe

[17:55:20] <dstufft> the only reason it stopped was because we couldn't safely download from PyPI

[17:55:30] <ionelmc> dstufft: what do you plan to do about the rewrite?

[17:55:40] <buck1> pypi isn't the most reliable thing anyhow

[17:55:45] <buck1> ionelmc: a rewrite of virtualenv?

[17:56:03] <ionelmc> buck1: there is such a thing, fully working

[17:56:13] <dstufft> ionelmc: not think too much about it until I have less things on fire :)

[17:56:27] <buck1> ionelmc: where is it/

[17:56:29] <buck1> ?

[17:56:42] <ionelmc> buck1: https://github.com/ionelmc/virtualenv

[17:56:51] <buck1> i'm working full time on some virtualenv monkey patches =/

[18:05:02] <ionelmc> buck1: what sort of patches

[18:05:15] <ronny> ionelmc: btw, when will it be released?

[18:05:37] <buck1> ionelmc: mainly to install, run my pip monkey patches =X

[18:05:50] <ionelmc> ronny: i've put some releases here https://anaconda.org/ionelmc/virtualenv

[18:06:23] <ngoldbaum> ionelmc: you use virualenv with anaconda? for some reason i thought that didn't work.

[18:06:43] <ionelmc> ngoldbaum: noo, i just use their free hosting service :)

[18:07:00] <ionelmc> they have free "pypi hosting"

[18:07:16] <ngoldbaum> ah, i see, since virtualenv is taken on pypi

[18:07:43] <buck1> ionelmc: your circleci failed

[18:07:51] <ionelmc> yup

[18:08:02] <ionelmc> still thinking about those failures

[18:11:09] <buck1> ionelmc: i did fix the python3-future problem though

[18:11:21] <buck1> the re-exec strategy currently in use isn't great

[18:11:40] <ionelmc> it's beyond hope

[18:11:46] <buck1> naw

[18:11:48] <buck1> it's fixed

[18:12:31] <ionelmc> yeah i know, but too much paint to fix

[18:12:38] <ronny> ionelmc: btw, do you know how to make conda pacakges? i#d like to repackage pytest

[18:12:39] <buck1> i've done the pain

[18:13:11] <ionelmc> ronny: the thing that irks me with conda is that they don't support pure python packages

[18:13:32] <ronny> ionelmc: what do you mean by "pure python"

[18:13:58] <ionelmc> you can't install pure python stuff from pypi with conda

[18:14:03] <ronny> for a actual distributor is pure insanity to have more than a single distribution package format

[18:14:17] <ionelmc> nor they have a "convertor"

[18:14:25] <ionelmc> i think they should have a convertor

[18:14:42] <buck1> is there sufficient reason for a new format?

[18:15:01] <ionelmc> buck1: he means they have a custom format for their packages

[18:15:01] <ronny> for a distributor its also pure insanity to have unreviewed pacakges form a open system

[18:15:47] <ionelmc> to me it seems busy-work to repackage for conda, it makes no sense to do it from maintainer's perspective

[18:15:56] <ionelmc> it does make sense for users, sure

[18:16:18] <ionelmc> but for maintainer is just more boilerplate to dump in your project

[18:16:24] <ronny> ionelmc: if its automatable and travis-defferable, i#d hallyly put it into the build pipeline

[18:16:38] <dstufft> I just ignore conda tbh

[18:16:50] <dstufft> just like I mostly ignore apt and yum and such

[18:17:13] <ionelmc> bitter competition :)

[18:17:40] <dstufft> Nah

[18:18:05] <dstufft> I've helped them on a few of their issues to setup better security defaults

[18:18:10] <dstufft> and pointed them towards TUF

[18:18:45] <dstufft> it's just another platform, like Debian, Ubuntu, etc. The most interesting part is that it's a cross platform, platform.

[18:20:04] <dstufft> I just don't have much interest in using Python packages that come from a redistributor :)

[18:21:10] <buck1> ionelmc: sure. i was asking what made them think it was worthwhile. seems like a terrible pain

[18:22:03] <dstufft> the science community and python packaging has a bit of a rocky history

[18:22:05] <ionelmc> buck1: they need a different format cause they package non-python stuff too

[18:22:26] <buck1> ah. i've done that on pypi

[18:22:36] <buck1> not easy by any means

[18:22:41] <ionelmc> now question is, could they have used wheels ?

[18:22:44] <ionelmc> :)

[18:22:54] <buck1> not for linux, and not without wheel 0.26.0

[18:23:05] <dstufft> The answer is yes (or pretty close to yes) but it'd require a time machine :D

[18:24:02] <dstufft> (I think Conda and Wheel started roughly around the same time period, conda might have started a little earlier than wheel)

[18:24:36] <ionelmc> speaking of that

[18:24:44] <ionelmc> why don't pip support eggs natively?

[18:24:57] <buck1> -2

[18:25:07] <ionelmc> humour the question

[18:25:12] <dstufft> hysterical raisens

[18:25:39] <buck1> ionelmc: it was getting rid of eggs that made pip successful imo

[18:25:45] <ionelmc> dstufft: elaborate

[18:26:35] <buck1> ionelmc: as a package format or an installation format, or both?

[18:26:53] <buck1> s/package/distribution/

[18:27:52] <ionelmc> package format

[18:28:19] <ionelmc> i never really understood that part

[18:28:43] <ionelmc> the installation format sure, it has comprehensible issues

[18:29:14] <buck1> that's the bit i'm -2 on. the distribution format -0

[18:29:29] <buck1> dont know why anyone would want

[18:30:54] <dstufft> ionelmc: I suspect largely just because it's hard to disentangle the two formats, nobody had ever done it, and now we have wheel and there's little reason to go backwards

[18:32:23] <ionelmc> dstufft: so it basically boils down to reimplementing the egg reading parts from setuptools

[18:32:38] <ionelmc> dstufft: but wheel does in fact already have a converter right?

[18:32:54] <buck1> looks like it

[18:33:08] <ionelmc> i'm just wondering, did no one really complain about not being able to install all those windows eggs!?

[18:35:10] <ionelmc> buck1: circleci has some issues with guess what, egg installs

[18:35:29] <buck1> i dont see how that makes any sense

[18:35:40] <ionelmc> those inject some old and broken stuff at the top of sys.path, breaking my tests

[18:35:55] <buck1> yes eggs are terrible

[18:35:57] <ionelmc> (regarding the circleci failures)

[18:36:07] <ionelmc> i had hoped they would fix it

[18:36:14] <buck1> they have eggs laying around?

[18:36:18] <ionelmc> yeah

[18:36:21] <buck1> ionelmc: you have sufficient control to rm them before you start

[18:36:29] <buck1> or wahtever other solution you prefer

[18:37:00] <ionelmc> would be tricky me thinks

[18:37:19] <buck1> how come

[18:37:22] <ionelmc> since i rely on those eggs to run anything

[18:37:24] <buck1> ionelmc: you know you can ssh in?

[18:37:29] <buck1> seems dubious

[18:37:31] <ionelmc> oooh

[18:37:33] <ionelmc> right

[18:37:36] <ionelmc> doh!

[18:37:58] <buck1> ionelmc: there's probably one section of the config that puts those eggs there, replace it with pip meb

[18:38:17] <buck1> all of it is overrideable in my experiene

[18:38:20] <ionelmc> damn it why didn;t i think of that

[18:38:22] <ionelmc> :D

[18:39:14] <ngoldbaum> buck1: conda can package non-python things, i think that's the origin of a lot of the confusion above

[18:39:36] <buck1> ngoldbaum: you can with wheel too, as of very recently

[18:39:38] <buck1> but it's not simple

[18:39:56] <buck1> and of course you cant host anything linux on pypi

[18:39:56] <ngoldbaum> OTOH conda could do that 3 years ago :)

[18:40:12] <ngoldbaum> not that conda is great by any means

[18:40:15] <buck1> yes, dstufft mentioned it would have worked if anaconda had a time machine

[18:40:32] <ngoldbaum> it sort of accidentally works on linux due to binary compatibility

[18:40:49] <buck1> ?

[18:40:57] <buck1> what about libpng et al

[18:41:08] <buck1> they conda package that too i suppose?

[18:41:13] <ngoldbaum> e.g. they don't package the entire C ecosystem, they just compile on a really old system so even though peopel have newer libraries installed on their systems it still "works"

[18:41:44] <ngoldbaum> one big example is glibc, but they also link against random system libraries a lot, i've noticed

[18:41:49] <buck1> seems very dubious

[18:42:13] <ngoldbaum> well, packaging e.g. glibc in a relocatable fashion is very hard, so i guess they just gave up on it?

[18:42:20] <ngoldbaum> and most people don't notice this stuff

[18:42:20] <buck1> even if there's abi compatibility, the links are usually against a specific libc, unless they compiled weird

[18:42:25] <ngoldbaum> it works in ~98% of cases

[18:44:02] <dstufft> turns out there aren't many linux's that don't use glibc

[18:44:16] <dstufft> too bad, because MUSL is pretty cool

[18:44:46] <buck1> dstufft: but the dynamic link is agaginst libc.so.x.y.z specifically, which will rule out older, newer libcs

[18:44:52] <buck1> i'm surprised it's not exploding a lot

[18:45:06] <dstufft> it won't rule out newer

[18:45:10] <dstufft> as long as th emajor version is the same

[18:45:21] <buck1> if the link is to libc.so.x

[18:45:35] <buck1> ah i guess it is

[18:46:47] <ngoldbaum> although a side effect of compiling on RHEL5 (I think that's what they use) is that they're on a very old GCC, so the compiled code will be substantially slower (i've measured ~25%) than if compiled using a recent compiler

[18:46:55] <ngoldbaum> which is why i don't use anaconda for my personal stuff

[18:47:07] <ngoldbaum> i'll still recommend it to people who don't how how to set up a compiler environment

[18:47:10] <buck1> you and your prifiling

[18:47:14] <ngoldbaum> or who are on windows

[18:50:12] <dstufft> ngoldbaum: I assume people can compile using a newer GCC when making wheels? :D Binary ABI shit makes my head hurt

[18:50:57] <ngoldbaum> dstufft: maybe? I think you have the same problem in the setuptools ecosystem if you're compiling a wheel that depends on an external C library.

[18:51:11] <dstufft> static linking!

[18:51:20] <ngoldbaum> sure, but you can't static link everything :)

[18:51:32] <ngoldbaum> it's possible to static link C libraries into wheels now?

[18:51:57] <dstufft> you can do whatever you want :) cryptography statically links OpenSSL into OSX and Windows wheels

[18:52:11] <dstufft> can't distribute linux binary wheels on PyPI yet

[18:52:14] <ngoldbaum> oh really?

[18:52:20] <ngoldbaum> does that build an _ssl module?

[18:52:42] <dstufft> it provides it's own bindings into ssl, it doesn't shadow/replace the stdlib ssl module

[18:52:42] <ngoldbaum> that might fix my woes with compiling python on OSX from source

[18:52:44] <[Tritium]> Wheels are just zipfiles... if you can statically link your library into your own shared library... you can put it in a wheel

[18:54:01] <buck1> ngoldbaum: is why linux wheels are disallowed on pypi

[18:54:15] <dstufft> for now anyways

[18:54:31] <buck1> dstufft: if we just assert all binaries are statically linked, call it ok

[18:54:33] <buck1> :D

[18:54:50] <buck1> or linked to things also in the venv i supose

[18:54:53] <[Tritium]> "lxml...now comes WITH glibc!"

[18:54:59] <buck1> yay

[18:55:02] <buck1> i suppose

[18:55:03] <dstufft> you can't really statically link glibc, it breaks badly IIRC

[18:55:13] <dstufft> you can with other libcs though

[18:55:16] <[Tritium]> someone actually tried it?

[18:55:29] <ngoldbaum> yes, even the gentoo prefix uses the system glibc

[18:55:29] <buck1> i haven't had problems, but i havne't tested extensively

[18:55:50] <dstufft> no idea if you can load a .so linked against not-glibc into a python linked against glibc though

[18:55:55] <[Tritium]> I dont think binary wheels for gentoo will ever be a thing

[18:59:51] <tdsmith> anaconda has a bunch of libraries like libpng and libxml around that mess things up sometimes when anaconda users try to build homebrew things that use python; i assume that's a conda thing and not an anaconda thing but idk really

[19:00:19] <ngoldbaum> yes, i wouldn't combine homebrew and anaconda either

[19:00:28] <ngoldbaum> well, i wouldn't combine any two python environments

[19:02:23] <buck1> eg: pip and apt

[19:02:30] <dstufft> tdsmith: I think it's an anaconda thing

[19:02:47] <dstufft> tdsmith: afaik conda is the package manager, anaconda is the distribution of stuff you can install by default

[19:12:52] <tdsmith> can i conda install libpng?

[19:13:10] <ngoldbaum> yup

[23:53:09] <ionelmc> gotta love the new "readme" release

[23:53:18] <ionelmc> definitely *not* the right way to release anything

Log file Viewer

Help | Karma | Search:

#pypa logs for Monday the 4th of January, 2016