pmxbot IRC Log Viewer

[01:10:31] <blr> Hey there, has there been any discussion around implementing something akin to npm's deprecate? https://www.npmjs.org/doc/cli/npm-deprecate.html

[01:12:50] <blr> presumably this would first require a user to authenticate with pypi via pip

[01:17:33] <dstufft> it's something i'd like to do yes

[01:18:17] <blr> it seems like an important gap to fill

[01:19:00] <blr> how much work would there be to do before something like that could be implemented dstufft?

[01:19:15] <dstufft> most likely it won't happen until PyPI 2.0 is deployed

[01:20:26] <blr> right, but presumably significant changes to pip would be needed too?

[01:43:45] <dstufft> probably not signifcant no

[01:43:49] <dstufft> but some would be needed yes

[01:43:54] <dstufft> but PyPI's side would need to come first

[01:53:38] <blr> right

[02:05:28] <blr> thanks, look forward to the pypi 2 release

[04:19:26] <Ivo> dstufft: still having fun with untraceable timeouts?

[04:26:52] <Ivo> oh god, #1881

[06:03:06] <amitprakash> How do I distribute python scripts that are part of a project via pypi? First of all, I'd like pip to install these scripts as executable under bin/ and second, how do I specify the script to use the local python version available [ such as use venv python if installed in venv or system python if system wide etc ]

[06:17:58] <amitprakash> nm, figured it out :D

[06:31:07] <Ivo> amitprakash: setuptools' entrypoints keyword in the setup() function of your setup.py

[11:05:53] <agronholm> more specifically, console_scripts

[11:18:30] <Ivo> ionelmc: in setup.cfg the correct section for wheel is now [bdist_wheel], not [wheel]

[11:18:48] <Ivo> changed in 0.23

[11:19:07] <Ivo> old ones still partially works but is discouraged

[11:27:11] <ionelmc> Ivo: aah, thanks

[11:27:27] <ionelmc> is [bdist_wheel] supported from older versions?

[11:28:15] <Ivo> new in 0.23

[11:28:39] <Ivo> but iirc python-tags doesn't work under [wheel]

[11:28:57] <Ivo> using [bdist_wheel] allows you to specify them on the command line as well

[11:29:20] <Ivo> python setup.py wheel --universal, etc

[11:31:10] <ionelmc> Ivo: python-tags ?

[11:31:31] <ionelmc> so i should have them both for a while right ?

[11:31:43] <ionelmc> just in case someone wants to use older wheel

[11:31:58] <Ivo> why would they ever want to do that

[11:32:04] <ionelmc> on the other hand, doesn't sound reasonable to use old tools

[11:32:10] <Ivo> wheel 0.23 is strictly better than 0.22

[11:32:26] <Ivo> and its really installable anywhere other than pip atm

[11:32:44] <agronholm> [wheel] seems to work too

[11:32:49] <agronholm> I'm on 0.23

[11:33:04] <agronholm> but yeah you said that already

[11:33:22] <ionelmc> Ivo: what did you mean - python-tags doesn't work ?

[11:33:36] <agronholm> there are no deprecation warnings or anything

[11:33:38] <Ivo> under [wheel]

[11:33:50] <Ivo> i didnt think so but maybe i got the code wrong

[11:34:34] <agronholm> the wheel docs still talk about distribute

[11:34:40] <agronholm> maybe that should be fixed?

[11:36:42] <Ivo> no thats correct, python-tag won't do anything if under a [wheel] section

[11:37:17] <ionelmc> that's a 0.23 feature right?

[11:37:25] <Ivo> yh

[11:37:38] <Ivo> yes

[11:39:38] <agronholm> pip install wheel[tool]: no matches found

[11:39:46] <agronholm> ^- wtf?

[11:43:05] <Ivo> is a bit weird

[11:43:07] <Ivo> https://bitbucket.org/pypa/wheel/src/79e669d9f170f5c653c674ac5177419580595d62/setup.py?at=default#cl-45

[11:44:33] <ionelmc> wooot

[11:44:42] <ionelmc> what does ':python_version=="2.6"': ['argparse'], do

[11:44:53] <ionelmc> is it loaded automatically ?

[11:45:00] <ionelmc> when py2.6?

[11:45:11] <agronholm> it installs argparse on python 2.6

[11:45:26] <ionelmc> uh... where is this documented?

[11:45:30] <ionelmc> didn't know about this

[11:45:38] <agronholm> neither did I

[11:45:43] <ionelmc> and it works with wheels too right?

[11:45:45] <agronholm> I don't think it works yet

[11:45:56] <agronholm> but I wouldn't know

[11:46:04] <agronholm> maybe it's a brand new setuptools feature

[11:49:56] <Ivo> support for them was added in setup.cfg for wheels

[11:50:04] <Ivo> I'm not sure about setuptools tho

[11:52:21] <Ivo> they're specified here tho

[11:52:23] <Ivo> http://legacy.python.org/dev/peps/pep-0345/#environment-markers

[11:55:10] <tomprince> agronholm: "no matches found" sounds like it is from the shell. Try `pip install "wheel[tool]"`

[11:55:29] <Ivo> tomprince: look at my bitbucket link above

[11:58:38] <agronholm> got it

[11:58:41] <agronholm> tomprince: thx

[12:00:19] <agronholm> wheel keygen does nothing

[12:00:33] <agronholm> and there is not a hint for how to proceed in the wheel docs

[12:01:33] <agronholm> it says "Install wheel[signatures] (requires keyring, dirspec) for signatures."

[12:01:36] <agronholm> but I already did that

[12:03:44] <ionelmc> is Requires-External used anywhere now?

[12:22:37] <Ivo> not that I know

[12:22:41] <Ivo> its kinda useless

[12:55:26] <Ivo> agronholm: after looking at the code out of interest, wheel stores it in ~/.config/wheel/wheel.json and ~/.local/share/python_keyring/keyring_pass.cfg

[12:56:21] <agronholm> stores what?

[12:56:32] <Ivo> the keys it generates

[12:56:33] <Ivo> *eky

[12:56:36] <Ivo> *key

[12:56:55] <agronholm> but it's not generating anything

[12:57:04] <Ivo> $ wheel keygen generated those two files for me

[12:57:08] <agronholm> not for me

[12:57:15] <agronholm> it still complains that I need to install wheel[signatures]

[12:57:21] <agronholm> which I already have

[12:57:39] <Ivo> i just went and installed the dependencies manually

[12:58:21] <Ivo> pyxdg and keyring (for linux)

[12:58:37] <agronholm> so is pip or setuptools broken?

[12:58:55] <agronholm> since the [signatures] extra doesn't install anything

[13:00:26] <agronholm> also why do I need to set up the WHEEL_TOOL command?

[13:02:25] <agronholm> env variable that is

[13:02:34] <agronholm> can't wheel look it up on PATH?

[13:06:26] <Ivo> never heard of that before

[13:07:18] <agronholm> heard of what

[13:08:16] <agronholm> the requirement to set up WHEEL_TOOL env variable to be able to sign wheels is stated right there in the wheel docs

[13:12:38] <Ivo> needing WHEEL_TOOL or what its needed for

[15:05:12] <pmxbot> jaraco pushed 2 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :

[15:05:12] <pmxbot> Remove superfluous import

[15:05:12] <pmxbot> Extract variable for clarity.

[15:52:00] <pmxbot> jaraco pushed 3 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :

[15:52:00] <pmxbot> Cleanup ignore files

[15:52:00] <pmxbot> Cleanup fixture using tmp and monkeypatch

[15:52:00] <pmxbot> Merge pull request #9 from Ivoz/integration-pr

[15:59:06] <Ivo> jaraco: ever thought of pep8'ing setuptools' codebase?

[16:00:04] <jaraco> Ivo, I'm doing it slowly, piece-by-piece.

[16:00:40] <Ivo> mostly grunt work that, I could help out if you'd like

[16:00:45] <jaraco> If you want to help, feel free. Just please consider separate commits for each class of change.

[16:01:01] <agronholm> each class means what here

[16:01:14] <jaraco> Think PEP8 error codes

[16:01:28] <jaraco> But it's okay if it encompasses a few related ones.

[16:01:35] <jaraco> There's no hard and fast rule.

[16:01:43] <agronholm> I would think "pep8 fixes" would cover it

[16:01:51] <Ivo> jaraco: also, might consider moving jaraco/setuptools to pypa/setuptools ?

[16:01:52] <agronholm> *should cover

[16:01:59] <jaraco> Having separate commits makes it easier to review/blame/backout.

[16:02:16] <Ivo> more people might discover being able to contribute to it under the pypa account

[16:02:39] <jaraco> Also, provides more meaningful changelog. Instead of "pep8 fixes", it's "added whitespace after comma-separated parameters"

[16:03:07] <agronholm> what's the point in such fine grained separation?

[16:03:12] <agronholm> I've never seen anyone do that

[16:03:12] <jaraco> Ivo, I'm not yet ready to make github an officially-supported repo.

[16:03:21] <agronholm> it's always "pep8 fixes" everywhere

[16:03:21] <jaraco> Partially to avoid confusion.

[16:03:32] <agronholm> confusion about what?

[16:03:43] <Ivo> jaraco: you could disable issues for it, only allow PRs

[16:03:50] <jaraco> But also to keep the integration with the current bitbucket project management.

[16:04:07] <agronholm> how are the two issues related?

[16:04:08] <Ivo> It's basically a "this is a mirror and you can also submit PRs to it"

[16:04:39] <Ivo> well you wouldn't want to keep the issue tracker on for the gh project or you'd have two issue trackers

[16:04:54] <jaraco> agronholm, if the point isn't apparent in providing more information, then perhaps that information isn't of value to you. It's valuable to me.

[16:05:08] <agronholm> what do YOU do with the information then?

[16:05:24] <jaraco> agronholm, review/blame/backout

[16:06:01] <jaraco> If a change has unintentional functional changes, it can be referenced separately.

[16:06:15] <jaraco> It's always possible to collapse a series of changes into a single, but the opposite is not possible.

[16:06:20] <jaraco> (mechanically)

[16:06:32] <agronholm> it would be easier to just back out of the whole pep8 commit and fix it

[16:06:48] <agronholm> the trouble is, a proper IDE can fix several classes of pep8 issues with one keystroke combo

[16:07:01] <agronholm> it's a LOT more work to do them manually

[16:07:21] <jaraco> agronholm, I don't want to impose extra work. If the work happens in one keystroke, and it's more work to split it out, then don't bother.

[16:07:32] <jaraco> (splitting it out)

[16:07:35] <agronholm> ok

[16:07:52] <dstufft> RIP 20 spaces between each function

[16:08:13] <Ivo> 20?

[16:08:27] <agronholm> so which one is the official setuptools repo

[16:08:35] <Ivo> bitbucket

[16:08:42] <agronholm> which one? pypa/setuptools?

[16:08:46] <Ivo> ja

[16:08:49] <agronholm> ok

[16:09:02] <dstufft> wait

[16:09:06] <jaraco> Consider something like: https://github.com/rackspace/pyrax/pull/304

[16:09:13] <Ivo> dstufft: you think moving pip search to use PackageFinder (instead of XMLRPC) could be a good target to get in for 1.6?

[16:09:15] <dstufft> jaraco accepts PRs on github.com/jaraco/setuptools?

[16:09:39] <jaraco> In that PR, I made several Python 3 improvements, which I could have made as one commit, including whitespace adjustments. But by making the commits separately, it's much easier to review and separate different types of changes.

[16:09:44] <jaraco> dstufft, yes

[16:09:46] <dstufft> welp

[16:09:55] <dstufft> one less thing I have to use Hg for

[16:09:56] <Ivo> yes, but apparently that's not super public knowledge yet

[16:09:56] <jaraco> bitbucket is official

[16:10:03] <agronholm> should I use hg or git? bb uses hg at least

[16:10:11] <agronholm> I prefer git these days

[16:10:23] <dstufft> once warehouse kills PyPI legacy then CPython will be the only thing I have to use hg for :3

[16:10:45] <dstufft> Ivo: not sure you can actually replace xmlrpc for that

[16:11:00] <dstufft> Ivo: the simple API doesn't have descriptions

[16:11:12] <Ivo> I saw.. carljm? mention the possibilty in an issue ages ago

[16:11:21] <Ivo> but then nobody did anything towards it

[16:12:05] <dstufft> Ivo: yea but do ``pip search requests``

[16:12:12] <dstufft> and look at the output

[16:12:18] <dstufft> where are you going to get that info from

[16:13:03] <Ivo> well, either that, or add the code so that xmlrpc can use a proxy

[16:13:25] <dstufft> that sounds reasonable

[16:14:18] <dstufft> it'd be best to make it so xmlrpc can use the requests session we already have

[16:17:13] <Ivo> find_requirement is a big function.

[16:17:31] <dstufft> we have a lot of big functions

[16:17:32] <dstufft> :[

[16:28:36] <agronholm> jaraco: would you insist on the standard 79 column limit or allow a wider maximum?

[16:28:58] <agronholm> some of the lines are going to look a bit ridiculous if I have to split them at 79 columns

[16:32:13] <jaraco> agronholm, I believe the community has settled on 79 columns. I don't see why setuptools is special.

[16:32:36] <agronholm> I use 120 cols in my own projects

[16:32:44] <jaraco> If it makes lines look rediculuous, then the redicule should be relayed to the PEP.

[16:33:06] <agronholm> I talked to guido about this two years ago at pycon

[16:33:32] <jaraco> What came of that discussion?

[16:33:35] <agronholm> he said it was more of a guideline

[16:33:58] <agronholm> he didn't agree with my viewpoint

[16:33:59] <jaraco> Yes, but so is spaces vs. tabs

[16:34:15] <agronholm> what project actually uses tabs?

[16:34:36] <jaraco> Before PEP-8, about half of them.

[16:34:39] <agronholm> the trouble with tabs is that depending on settings it can look quite different on different machines

[16:34:55] <agronholm> and smart editors will produce a number of spaces when tab is pressed anyway

[16:35:45] <agronholm> with a 79 column limit, more than half of the horizontal screen estate is left unused on my workstation

[16:36:22] <agronholm> and I often find that lines just get too long to comfortably fit within the limit

[16:36:23] <jaraco> If it were my personal preference, I'd used tabs and no line limits.

[16:36:39] <jaraco> And I'd expect the editors to give each developer a suitable experience.

[16:37:20] <jaraco> But I've been convinced by the majority that PEP-8 is the most community-friendly style.

[16:37:48] <agronholm> yet both pep8 and flake8 tools have a special setting for adjusting the max line width

[16:37:59] <agronholm> because so many people disagree with the 79 column limit

[16:38:19] <agronholm> but I will respect it in setuptools

[16:39:09] <jaraco> Yes, please. And thanks.

[16:49:52] <Alex_Gaynor> ==dstufft

[17:12:42] <tomprince> agronholm: On my laptop, I can fit *exactly* two 80 column editors.

[17:13:04] <Alex_Gaynor> On my 24" monitor I can fit about 1.5 80 col editors

[17:13:07] <tomprince> And on my desktop, in portrait mode, two ~90 column editors.

[17:13:42] <tomprince> How come I can fit more than that on my 10" monitor? :)

[17:14:11] <Alex_Gaynor> You don't use font size 724

[17:22:04] <Ivo> agronholm: you should get an editor which can edit two files in two panes

[17:22:12] <Ivo> helps alot

[17:22:14] <agronholm> I already have one

[17:22:22] <agronholm> normally I prefer to split them horizontally

[17:23:13] <dstufft> why don't you do everything exactly like I do you heathen

[17:23:47] <agronholm> different desktop setup perhaps

[17:24:03] <Ivo> columns4life

[17:25:07] <agronholm> my IDE spotted a bug in easy_install.py

[17:25:27] <agronholm> in rmtree() there is a "raise" statement without an enclosing exception handler

[17:25:44] <Ivo> awesome, chuck up a pr for it

[17:25:56] <agronholm> hmm

[17:26:09] <agronholm> it seems like it's called from within an exception handler

[17:26:12] <agronholm> so, false alarm

[17:27:40] <Ivo> lol at there being a vendored rmtree() in the code in the first place

[17:27:54] <dstufft> pip.util.rmtree

[17:28:30] <dstufft> supposidly ther eis a race condition in shutil.rmtree

[17:28:31] <dstufft> :[

[17:29:08] <Ivo> is that that thing you were having fun with alex about the other day

[17:30:02] <Ivo> de-angryfying musacs -> https://www.youtube.com/watch?v=rq1Iv3DkwVs

[17:30:42] <dstufft> Ivo: no

[17:30:45] <dstufft> that is something else

[17:30:47] <dstufft> don't know what

[17:30:58] <dstufft> two completley unrelated chnages are causing pip to hang forever in the test suite

[17:30:59] <Ivo> oh, joy

[17:31:19] <Ivo> obviously butterflies are fluttering in the code

[17:33:09] <agronholm> ok, setuptools.command is pep 8 compliant now

[17:33:17] <agronholm> forking, pushing and sending a PR

[17:34:31] <agronholm> hm, the test suite does not pass

[17:34:44] <agronholm> let's see if does without my changes

[17:35:36] <agronholm> no, it doesn't

[17:36:09] <agronholm> ok I was clearly doing it wrong

[17:36:36] <agronholm> yup, passes

[17:39:06] <agronholm> jaraco: all yours

[18:32:20] <carljm> Ivo, dstufft: personally I think that "search finds the same packages that install would find" is more important than having descriptions in search. But I also don't really use search, so maybe I'm wrong there.

[18:32:46] <carljm> Almost seems like there should be "pip search" and "pip pypi-search"

[18:33:03] <carljm> Or else leave "pip search" as-is but introduce a "pip find" that uses PackageFinder.

[22:09:56] <dstufft> carljm: so I don't use search, so I have no idea what people would find useful

[22:12:58] <carljm> yep. the only data I have is "people file bugs because search doesn't find the same packages as install"

[22:13:16] <carljm> but that's only half the data we need, I don't know how many "search is crappy" bugs we'd get if it didn't include descriptions :-)

[22:13:33] <carljm> so: with insufficient data, status quo wins, i guess

[22:14:13] <dstufft> we could post an issue or something and twitter/distutils-sig it and stuff

[22:14:15] <dstufft> and try to get more data

[22:14:45] <dstufft> the other option is I can extend the simple API to add extra stuff

[22:14:52] <dstufft> maybe

Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Wednesday the 18th of June, 2014