pmxbot IRC Log Viewer

[11:13:20] <xafer> dstufft, any clue when you could have time to check https://github.com/pypa/pip/pulls/xavfernandez ?

[11:26:37] <Ivo> xafer: in #2335 you're not taking --no-compile into account afaik

[11:28:14] <xafer> Ivo, sure it's #2335 ?

[11:28:36] <Ivo> yeah

[11:28:47] <Ivo> looking at adding .pyc unconditionally

[11:29:14] <Ivo> but probably the weirder thing is InstallationRequirement in req_install is also responsible for uninstalling

[11:29:24] <Ivo> when a req_uninstall.py exists as well

[11:29:52] <xafer> well we always try to remove pyc when uninstalling

[11:30:33] <xafer> there is no --no-compile option when uninstalling :o

[11:30:44] <Ivo> xafer: it looks incredibly weird when you haven't yet released that "add_dist_record", in "InstallationRequirement", is actually logic for uninstalling something

[11:30:49] <Ivo> *realised

[11:31:41] <Ivo> could probably use a refactor

[11:31:47] <xafer> well add_dist_record is added to UninstallPathSet class

[11:33:27] <Ivo> seems like InstallRequirement is a bit of a god object

[11:34:26] <Ivo> well not seems, pretty much is

[11:35:51] <xafer> yes pip could benefit a lot from refactoring :) that's what I'm trying to do, with small steps

[11:37:08] <Ivo> so could be good to specialise what each format of package needs to do to install/uninstall itself into different objects

[11:38:26] <Ivo> ok so I don't believe add_dist_record should reside in UninstallPath

[11:38:33] <Ivo> Set

[11:39:11] <Ivo> surely collating those files is not all that it is for

[11:39:29] <Ivo> pip show -f needs similar functionality, for example

[11:47:03] <xafer> yup search_packages_info has quite a lot of similarities with uninstall :-/

[15:11:08] <straycat> Are there any plans to add a project_source_repo attribute or something similar to pypi package metadata, at the moment there's no reliable way to determine a project's source repo. Some use homepage_url but it's not standard or even convention

[16:22:52] <ionelmc> gotta love failures where not even the tracebacks can be rendered

[16:22:58] <ionelmc> :-(

[16:30:17] <sigmavirus24> ionelmc: those are the easiest to debug

[16:30:56] <ionelmc> sigmavirus24: with a WONTFIX resolution?

[16:31:03] <ionelmc> lel

[16:31:14] <sigmavirus24> I said "debug" not "closebug" =P

[16:33:44] <sigmavirus24> "read the traceback"

[16:36:06] <ionelmc> sigmavirus24: i think you misread, there's no traceback to begin with, cause it can't be rendered

[16:37:20] <sigmavirus24> ionelmc: that's why it's the easiest to debug. because there's no debugging to do

[16:38:22] <ionelmc> sigmavirus24: i think there's a broken philosopher inside you :-)

[16:38:45] <sigmavirus24> ionelmc: maybe, maybe not. The real question is, what does it mean to be a broken debugger?

[16:42:19] <ionelmc> sigmavirus24: in my book a debugger is a person, for debugging is a process done by a person. there can be broken debugging tools, but the tool is not in itself a debugger - unless we're talking about a tool that can automatically find problems with your code

[16:44:38] <sigmavirus24> ionelmc: are we not all tools that automatically find problems with other people's code?

[16:46:58] <ionelmc> sigmavirus24: it usually slides the other way, cause it's hard to hate something impersonal

[16:47:17] <ionelmc> so tools get personified, eg: "evil site.py module"

[16:47:45] <ionelmc> that's a personification of an object, namely a module

[18:40:42] <msabramo> straycat: I believe Metadata 2.0 (PEP 426 or a related PEP proposes something like this)

[18:41:19] <msabramo> https://www.python.org/dev/peps/pep-0426/#changes-to-project-urls: "In addition to allow arbitrary strings as project URL labels, the new metadata standard also defines a recommend set of four URL labels for a distribution's home page, documentation, source control and issue tracker."

[18:41:40] <msabramo> better link: https://www.python.org/dev/peps/pep-0459/#project-urls

[18:42:21] <msabramo> it sounds like project_urls.Repository is what you are looking for?

[18:42:35] <msabramo> not sure what if any tools support Metadata 2.0

[18:43:24] <DanielHolth> there is not currently a way to specify those. it still all has to come from setup.py arguments

[18:43:54] <DanielHolth> also the PEP is not approved

[18:45:16] <agronholm> DanielHolth: should it be approved before the <, <=, >, >= operators start working in python version specifiers in setup.py/extras?

[18:45:42] <DanielHolth> y

[18:46:33] <agronholm> I guess I'll keep using setup.cfg until then

[18:47:22] <msabramo1> > still all has to come from http://setup.py/ arguments

[18:47:30] <msabramo1> ? How do you do that?

[18:47:42] <agronholm> huh?

[18:48:09] <msabramo1> is there a way of specifying repo and such with setup.py arguments or in setup.cfg?

[18:48:31] <agronholm> not to my knowledge

[18:48:51] <agronholm> you could point the project url to a bitbucket/github url

[18:48:52] <msabramo1> ok I must've misunderstood

[18:49:11] <msabramo1> yeah I usually set url to the repo

[18:49:27] <msabramo1> I hate it when people set the url to the PyPI page; not very useful :)

[18:50:13] <msabramo1> I kinda wish PyPI (or setuptools?) rejected attempts to do that

[18:50:45] <DanielHolth> some people only use pypi as the home page. if the docs are hosted there or linked from there it works okay

[18:51:18] <msabramo1> yeah but if I'm on the PyPI page and the URL says the same page, it's not useful

[18:51:38] <msabramo1> I'd much rather see a GitHub or Bitbucket repo

[20:02:08] <ionelmc> oh man the pypy package for ubuntu is really screwy

[20:02:26] <ionelmc> no BINDIR in sysconfig :-(

[20:56:06] <sigmavirus24> ionelmc: the one from deadsnakes or is there a real one now?

[20:57:06] <ionelmc> sigmavirus24: deadsnakes ppa doesn't have anything for pypy

[20:57:30] <ionelmc> no pypy here https://launchpad.net/~fkrull/+archive/ubuntu/deadsnakes

[20:58:54] <ionelmc> eeeh

[20:58:55] <ionelmc> https://travis-ci.org/ionelmc/virtualenv/builds/46241451

[20:59:02] <ionelmc> 3.2 works

[21:12:29] <sigmavirus24> wooooooooo 3.2

[21:28:05] <straycat> msabramo, cool thanks :)

[22:24:08] <dstufft> ErikRose: holy cow that matrix for pip versions

[22:24:24] <ErikRose> haha :-)

[22:25:01] <ErikRose> dstufft: Born of determined brute force and trawling through pip history a few weeks back.

[22:26:35] <ErikRose> I need to get a job running against pip master so I have advance notice of breaking changes.

[22:26:38] <dstufft> I don't think even RHEL ships a pip as old as you're testing against

[22:27:04] <sigmavirus24> dstufft: what's this for?

[22:27:15] <dstufft> sigmavirus24: https://github.com/erikrose/peep/blob/master/tox.ini

[22:27:17] <ErikRose> heh, now that the support is in there, it's cheap to maintain. Somebody at Mozilla actually had 0.6.2 installed; that's how it got in there.

[22:27:35] <dstufft> ErikRose: they are bad people and should feel bad

[22:27:40] <dstufft> 0.6.2 :((

[22:27:50] <dstufft> I wish I could force everyone to be on 1.5+

[22:27:51] <sigmavirus24> WOAH

[22:27:59] <ErikRose> Yeah, they're even worse once you get to know 'em. ;-)

[22:28:00] <sigmavirus24> what the what

[22:28:05] <dstufft> anything less than that is asking to get your computer MITM'd

[22:28:07] <ErikRose> Sometimes they use semicolons.

[22:28:22] <dstufft> ErikRose: heretics

[22:28:31] <ErikRose> What's the MITM vuln?

[22:28:45] <sigmavirus24> no verification of the https connection?

[22:29:31] <dstufft> ErikRose: prior to pip 1.3 there was zero attempt at verifying https, prior to 1.5 pip would silently hit random http URLs linked from people's /simple/ pages

[22:29:51] <dstufft> I mean I guess if they only ever use peep and verify it ahead of time it's ok

[22:29:54] <ErikRose> Ah. Under peep, it doesn't matter if we verify HTTPS, FWIW.

[22:30:02] <ErikRose> But yeah.

[22:30:03] <dstufft> but assumingly they installed peep somehow

[22:30:11] <dstufft> I'm guessing with a pip install peep :D

[22:30:31] <ErikRose> Peep used to be short enough to just read, and I advised people to do that. Since I had to add all that download code in 2.0, it's long.

[22:30:43] <ErikRose> So we're working on a good place to put a signed hash or something.

[22:30:55] <ErikRose> Still plan on submitting a pip PR one of these years

[22:32:22] <dstufft> luckily

[22:32:28] <dstufft> pip 6.0 now bothers people to upgrade

[22:32:31] <dstufft> >:]

[22:32:45] <ErikRose> That's spiffy.

[22:34:23] <dstufft> ErikRose: I'd argue that peep should still verify TLS fwiw, since TLS provides more than just protection against modification

[22:34:58] <ErikRose> I'd take a patch. I was just in a hurry to get 2.0 out and plug that horrendous security hole.

[22:35:23] <ErikRose> And for embeddability, I didn't want to start vendoring things (requests).

[22:35:38] <dstufft> although now adays on 2.7.9 I think it'll verify TLS anyways

[22:35:52] <ErikRose> Lucky for me

[22:36:14] <dstufft> I plan on keeping TLS verification in pip even when we get package signing :D

[22:36:15] <dstufft> yay for privacy

[22:36:23] <ErikRose> sure thing

[22:36:38] <ErikRose> Are you planning signing beyond the existing wheel stuff?

[22:37:45] <dstufft> ErikRose: yea

[22:37:55] <dstufft> the wheel stuff isn't generally useful, I doubt pip will ever support it

[22:38:15] <ErikRose> I was trying eariler today to figure out what it was good for. :-)

[22:38:34] <ErikRose> In the absence of some integration with a well-defended keyserver or author pinning, it doesn't do much against PyPI getting owned.

[22:38:58] <ErikRose> (Own PyPI, change the author of a package, add new bogus signature with new bogus author's key.)

[22:39:50] <dstufft> I think there was some particular non PyPI use case that it was added for, I wouldn't have bothered personally but whatever

[22:40:47] <dstufft> I don't see a ton of value in a format specific signature scheme tbh

[22:41:03] <ErikRose> As in specific to Python packages?

[22:41:15] <dstufft> as in specific to .whl

[22:42:02] <dstufft> signing should probably just treat the file as an opaque blob

[22:46:59] <ErikRose> I certainly support that.

[22:47:15] <ErikRose> I've been meaning to junk the PEP 4xx-whatever hash representation peep uses.

[22:47:28] <ErikRose> The question is always where to put the signature, of course.

[23:35:17] <ionelmc> why the hell egg get first on sys.path

[23:35:27] <ionelmc> regardless of what i have on PYTHONPATH

[23:35:31] <msabramo> ErikRose: thinking of sending a PR to add peep's signature verification to pip?

[23:35:37] <ionelmc> jaraco: ping

[23:35:47] <msabramo> cuz that would be pretty cool

[23:35:58] <buck1> ionelmc: because setuptools =/

[23:36:21] <buck1> my policy (and pip's) is dont use eggs

[23:36:31] <ionelmc> buck1: don't have a choice

[23:36:35] <buck1> ionelmc: how come?

[23:36:36] <ionelmc> i need a workaround :|

[23:36:42] <buck1> simply curious

[23:36:59] <buck1> ionelmc: workaround is to rm the egg and pip install?

[23:37:11] <ionelmc> buck1: i can't it comes from travis

[23:37:12] <ionelmc> eg https://travis-ci.org/ionelmc/virtualenv/jobs/46258656#L244

[23:37:42] <ErikRose> msabramo: Yep, for about 2 years now. :-)

[23:38:01] <pmxbot> jaraco pushed 1 commit to setuptools (https://bitbucket.org/pypa/setuptools/) :

[23:38:01] <pmxbot> Merge with 11.3.1

[23:38:19] <ErikRose> msabramo: Though for peep 2.0, I had to read what felt like most of pip's source code, including historical versions. So now the comprehension barrier to merging is lifted.

[23:38:28] <buck1> ionelmc: can i have a line number?

[23:39:28] <ionelmc> buck1: sure, https://github.com/ionelmc/virtualenv/blob/rewrite-pypy-support/virtualenv/builders/base.py#L192

[23:39:42] <ionelmc> you see, the pip wheel is beeing added to PYTHONPATH

[23:39:53] <ionelmc> however the egg (the older version) is always first

[23:40:03] <buck1> hm i meant for the travis log

[23:40:07] <ionelmc> meh, i need to read setuptools code now :|

[23:40:51] <buck1> ionelmc: i couldn't find anything egg-related in that travis log

[23:41:00] <ionelmc> buck1: 244

[23:41:12] <ionelmc> you see, old pip don't have `--isolated`

[23:41:27] <ionelmc> because it's loaded from the egg, not my wheel

[23:41:48] <jaraco> ionelmc: pong

[23:42:08] <buck1> ionelmc: i would have thought to see .egg in that traceback

[23:42:53] <buck1> looks like it's running from an unzipped virtualenv module

[23:43:14] <ionelmc> jaraco: how can i force setuptools to not inject some eggs first on sys.path

[23:43:20] <ionelmc> without removing said eggs

[23:43:26] <buck1> oh there's subprocesses going on

[23:44:49] <buck1> i would still think your env just doesn't have your virtualenv on its $PATH

[23:44:55] <buck1> no need for an egg to cause that behavior

[23:45:05] <buck1> could just get the system virtualenv version

[23:45:15] <ionelmc> they come from the global python site, the eggs

[23:45:18] <ionelmc> i think :-)

[23:45:37] <buck1> ionelmc: i'd want to see some extra output showing exactly where the subprocess is finding virtualenv

[23:45:44] <jaraco> ionelmc: I haven't done that myself, but I believe it's the code in easy-install.pth in site-packages that makes that happen.

[23:45:47] <buck1> env.run('python', '-c', 'import virtualenv; print virtualenv')

[23:46:39] <buck1> env.run('sh', '-c', 'which virtualenv; head -1 `which virtualenv`')

[23:46:53] <ionelmc> well i guess i could just upgrade the global pip

[23:47:09] <buck1> unwise

[23:47:09] <ionelmc> and pretend this never happened :)

[23:51:28] <ionelmc> buck1: ok, so this is a virtualenv rewrite, in case you haven't noticed :-)

[23:51:48] <buck1> i saw the branch name

[23:52:06] <buck1> not sure it pertains directly to your current difficulty

[23:55:41] <buck1> ionelmc: put those lines in your test, I think you may find your assumed issue isn't your issue

[23:55:58] <buck1> looks like $PATH issue to me

[23:56:29] <buck1> ionelmc: are you the pylibmc guy?

[23:56:45] <ionelmc> buck1: no

[23:56:51] <buck1> nvm :)

[23:58:52] <ionelmc> buck1: if you're curious, this is the problem

[23:59:00] <ionelmc> https://www.irccloud.com/pastebin/JkIN6hnS

[23:59:07] <ionelmc> note the egg

[23:59:37] <buck1> ionelmc: yea, that's convincing

Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Wednesday the 7th of January, 2015