Log file Viewer

[05:18:47] <r1chardj0n3s> dstufft: I've never used install_requires. I kinda assume it's pretty limited in its usage, given requirements.txt

[05:50:36] <dstufft> r1chardj0n3s: basically everything on PyPI that depends on something uses install_requires

[05:50:59] <r1chardj0n3s> except the stuff that uses requirements.txt...

[05:51:11] <dstufft> neither pip nor setuptools installs a requirements.txt automatically

[05:51:12] <r1chardj0n3s> or maybe I'm doing it wrong?

[05:51:28] <r1chardj0n3s> (and openstack is doing it wrong ;)

[05:51:37] <dstufft> the only way for foo in ``pip install foo`` to have dependencies is via install_requires

[05:51:39] <dstufft> ah openstack

[05:51:41] <dstufft> openstack is special

[05:51:50] <r1chardj0n3s> well....

[05:51:52] <dstufft> pbr translates a requirements.txt into a install_requirements

[05:52:12] <dstufft> which was the reason I wrote https://caremad.io/2013/07/setup-vs-requirement/

[14:25:08] <herrwolfe> Does it help to add RFR or 'request for review' to a ticket title to signal that a ticket is ready for review? Or are tickets just reviewed as long as tests are passing and WIP isn't in the title. This isn't meant to pester, I just want to try to avoid getting lost in the shuffle.

[15:11:26] <xafer> herrwolfe, I dont think there are any particular rules :)

[15:29:29] <herrwolfe> xafer: ah ok - thanks!

[15:41:10] <xafer> https://github.com/pypa/pip/pull/2142/ seems fine if that's the one you had in mind ?

[15:43:18] <herrwolfe> xafer: yes, that's the one!

[17:01:40] <dstufft> herrwolfe: tickets are basicalyl reviewed in.. whenever a core team member remembers to do it

[17:01:56] <dstufft> I try to periodically look at things, but I've been real bad at it lately since I've bene focusing on Warehouse

[17:02:20] <dstufft> I personally wouldn't feel bad if someone "pestered"

[17:05:30] <herrwolfe> sigmavirus24: thanks for your comments

[17:07:32] <sigmavirus24> herrwolfe: it's just a thing I do =P

[17:08:17] <herrwolfe> dstufft: ok - I'll stop feeling bad about bring up my ticket constantly! Have you thought about using github's labels for PR's? It isn't a perfect solution, but it can make it a bit easier to show that something is a work in progress, awaiting review, or awating feedback from the PR author. rackerlabs/mimic's repo makes use of them pretty nicely

[17:08:43] <dstufft> herrwolfe: can people who aren't committers add labels?

[17:08:46] <herrwolfe> dstufft: the only issue that I can see with it, is that one might need admin privileges to add lables

[17:09:10] <herrwolfe> dstufft: that, I'm not sure of. I'll look into it and get back to you

[17:12:10] <xafer> sigmavirus24, if you want PR to review, I might possibly find some :-°

[17:12:31] <sigmavirus24> dstufft: no

[17:12:40] <sigmavirus24> xafer: feel free to ping me in a few each week

[17:13:24] <dstufft> It might be time to look at non Github solutions as much as that pains me to say

[17:13:46] <sigmavirus24> dstufft: kallithea ;)

[17:14:06] <dstufft> sigmavirus24: lol

[17:14:45] <herrwolfe> dstufft: I'm getting the feeling one needs to have privileges to do it - which seems unhelpful but sensible, since you wouldn't want any user to be able to remove labels from other PRs

[17:19:44] <xafer> sigmavirus24, I've different sizes: several 20ish and one 100ish

[17:20:07] <sigmavirus24> xafer: what?

[17:20:17] <xafer> PR :o

[17:20:30] <sigmavirus24> line count or is that groupings of PRs?

[17:20:44] <sigmavirus24> xafer: if you send me 20 PRs, I'll just automate commenting "Why hasn't this been closed yet?"

[17:20:52] <sigmavirus24> xafer: I'm the author of github3.py. I can do that =P

[17:20:58] <xafer> line count ^^

[17:21:03] <sigmavirus24> Oh

[17:21:07] <sigmavirus24> Send me both

[17:22:05] <xafer> https://github.com/pypa/pip/pull/2506 and https://github.com/pypa/pip/pull/2505 then, mainly refactoring

[18:03:38] <xafer> sigmavirus24, thanks for the comments, will try to work on them in the next days

[22:01:34] <lifeless> hi so

[22:01:44] <lifeless> I have an odd wheel thing I'd love a pointer on

[22:01:53] <lifeless> https://bugs.launchpad.net/subunit/+bug/1430536

[22:04:25] <dstufft> lifeless: was there a space in the directory?

[22:04:42] <lifeless> not afaict

[22:05:51] <lifeless> dstufft: are script shebangs fixedup when a wheel is installed ?

[22:06:13] <dstufft> um

[22:06:19] <dstufft> maybe not

[22:06:33] <dstufft> we generate the correct entry points based

[22:06:34] <lifeless> https://github.com/testing-cabal/subunit/blob/master/setup.py

[22:06:38] <lifeless> is the setup.py

[22:06:45] <lifeless> its using scripts =

[22:06:50] <lifeless> not entry points

[22:06:52] <dstufft> I'm not sure if we do anything with scripts

[22:06:55] <dstufft> let me look

[22:08:25] <dstufft> lifeless: https://github.com/pypa/pip/blob/develop/pip/wheel.py#L68-L83

[22:08:32] <dstufft> looks like we'll fix it if it starts with #!python

[22:08:48] <lifeless> hah

[22:09:01] <lifeless> so if the interpreter being used to build the wheel generates a full path

[22:09:03] <lifeless> like in the bug

[22:09:09] <lifeless> it won't be fixed up

[22:09:18] <lifeless> I'd like to squash this so it can't bite again

[22:09:31] <lifeless> whether thats in my project or ideally upstream

[22:12:25] <dstufft> so

[22:12:45] <dstufft> PEP 427 (wheel) recommends a feature of rewriting #!python and #!pythonw

[22:13:12] <dstufft> beyond that we'd probably to think about it, can you file a ticket?

[22:13:33] <dstufft> and include what shebang lines are in the wheel

[22:13:51] <lifeless> I think its a bad data problem in the wheel

[22:14:06] <lifeless> e.g. bdist_wheel needs to handle odd interpreter lines that build_py created

[22:14:17] <lifeless> or whatever internal step did it

[22:14:28] <lifeless> and transform that on the way into the wheel

[22:14:34] <lifeless> where should a ticket go ?

[22:15:32] <dstufft> ah

[22:15:45] <dstufft> in that case, probably bitbucket.org/pypa/wheel

[22:50:36] <lifeless> dstufft: https://bitbucket.org/pypa/wheel/issue/135/bad-interpreter-lines-can-sneak-into

[23:00:16] <ronny> lifeless: thats correct behaviour there :)

[23:00:43] <lifeless> ronny: that makes me sad then

[23:01:17] <ronny> lifeless: the broken shebang is in package data, not a installed script, the script was *not* installed as a script, its merely shipped as package data

[23:01:31] <ronny> its strongly suggested to use entrypoints for scripts

[23:01:41] <lifeless> ronny: its a script in setup.py though

[23:03:43] <ronny> lifeless: yes, and what you pointed to was package data, not a installed script

[23:04:47] <ronny> lifeless: the propper way to get working scripts on all platforms is to use entrypoints

[23:05:26] <lifeless> so why does a script end up as package data?

[23:05:44] <lifeless> entrypoints not being usable locally is a real PITA

[23:06:03] <ronny> i suppose thats a bug from the seruptools script metadata conversion

[23:06:06] <lifeless> and subunit's primary build system is autoconf

[23:06:19] <lifeless> so switching to entrypoints is likely non-trivial

[23:06:32] <dstufft> We know it's a script

[23:06:39] <dstufft> it's not just arbitrary data

[23:06:44] <dstufft> it's a script in the .data/scripts dir

[23:07:06] <ronny> dstufft: how do those get propperly installed?

[23:07:36] <dstufft> define "properly installed", we copy them into the bin dir, and if the shebang is #!python or #!pythonw we rewrite the shebang to point to the real interpreter

[23:07:46] <dstufft> it's a supported feature that you can write scripts like that

[23:08:07] <dstufft> entry points are generally better, especially for cross platform things, but the old feature still works

[23:08:54] <ronny> dstufft: so if something makes a messy shebang then they dont get installed?

[23:09:07] <dstufft> they get installed, we just don't rewrite the shebang

[23:09:30] <ronny> i see

[23:10:50] <ronny> dstufft: so wheel itself has a bug if it puts scripts in there with broken shebang?

[23:11:59] <dstufft> yea, wheel is taking the shebang line of #!/usr/bin/env python that subunut has, and instead of putting that in byte for byte, it's doing it's own munging

[23:12:39] <dstufft> I'm betting it's because bdist_wheel basically works by running python setup.py install

[23:13:14] <dstufft> which means the munging that setuptools does is happening at wheel build time

[23:13:25] <ronny> yes

[23:13:34] <ronny> bdist_wheel uses a plain install

[23:13:57] <ronny> can the shebang fixing be disabled?

[23:14:46] <dstufft> unsure

[23:18:18] <ronny> dstufft, lifeless: cant be changed without a" major" command change in distutils, likely impossible

[23:18:59] <ronny> dstufft: either wheel needs to fix the scripts itself or it should stop supporting/shipping them

[23:20:22] <dstufft> well

[23:20:37] <dstufft> wheel could just monkeypatch distutils.command.build_scripts:first_line so that it matches nothing

[23:21:35] <ronny> oh, right

[23:21:44] <ronny> hmm, sometimes its just too oblivious ^^

[23:21:53] <dstufft> I mean it's kinda gross, but it'll work

[23:22:33] <ronny> i wonder if there is a fit monthy python quote to put before the monkeypatch

[23:22:36] <ronny> also good night