pmxbot IRC Log Viewer

[01:19:16] <sumanah> di_codes: am back online post-dinner and reviewing your PR

[01:23:33] <sumanah> di_codes: if you feel like giving https://github.com/pypa/twine/pull/320 a look, that'll help me

[03:52:45] <sumanah> Maybe tomorrow will be twine 1.10.1

[05:13:42] <sumanah> Thanks waseem18! I am about to head to bed

[05:14:57] <sumanah> waseem18: if you were about to do something else before I mentioned the contributors API stuff, it's ok to say in the issue "actually no, I need to work on something else first" to alert other people that they can pick it up :) just so you know. not advice, not an order

[05:16:09] <sumanah> no worries

[14:04:49] <sumanah> Now I'm trying to work out - under what circumstances Warehouse gives an error 503 https://github.com/h2oai/h2o-3/pull/2040/files

[14:11:14] <EWDurbin> sumanah: on uploads that's generally a timeout

[14:12:08] <EWDurbin> we're gonna be able to bump the timeout soon though!

[14:12:13] <sumanah> It doesn't seem like the kind of thing a packager should programmatically ignore, right EWDurbin ?

[14:12:14] <EWDurbin> right now our hands are tied by Heroku

[14:12:22] <EWDurbin> sumanah: hmmmm, probably not

[14:12:42] <EWDurbin> but it's a real live thing until we get upload.pypi.org off of heroku

[14:17:56] <EWDurbin> sumanah: prepping for that in that PR ^

[16:37:01] <sumanah> di_codes: just letting you know that I am checking out your branch locally and testing stuff and will then almost certainly give a thumbs-up and a merge and release this afternoon

[16:44:56] <sumanah> ok I find this hilarious. I am testing di_codes's setuptools branch. tried uninstalling setuptools in my venv, then running pip install git+https://github.com/di/setuptools@pep-566-updates

[16:45:00] <sumanah> can't do that without setuptools

[16:58:05] <Wooble> sumanah: I think I read about this in Godel, Escher Bach. :)

[16:58:14] <sumanah> Wooble: Ha! :)

[17:02:15] <sumanah> jaraco: thank you for being so clear and explanatory in your comments in https://github.com/pypa/setuptools/issues/980 which are helping me think about the problem I am having

[17:03:55] <sumanah> and now bootstrap.py exists when I ls, but not when I try to actually run it. lunch, then more investigation - or giving up which is also ok

[17:06:35] <jaraco> Oh, that’s strange. I would expect bootstrap.py to exist in general; it’s not deleted by any routine.

[17:12:14] <jaraco> I’ve been dabbling lately with extracting pkg_resources as a separate package (and vendoring it in setuptools), but the bootstrapping issues are multiplied when pkg_resources is a separate package.

[19:00:54] <sumanah> !logs

[19:00:54] <pmxbot> http://kafka.dcpython.org/channel/pypa-dev

[19:13:32] <sumanah> jaraco: I caught up on logs :) do you want more info on this bootstrap.py issue?

[19:14:20] <sumanah> ok, whoops, the file's there, but the command is not found, that's a different error

[19:15:26] <sumanah> when I see an error "RuntimeError: Cannot build setuptools without metadata. Run `bootstrap.py`" then what I try to do is ./bootstrap.py but evidently that does not work.

[19:15:33] <sumanah> "python bootstrap.py" does work. AHA.

[19:18:33] <sumanah> di_codes: is now a good time for you to try to help me? I want to actually test how your twine PR will work when I also have your setuptools branch set up (locally, in a virtualenv) and I am having a difficult time.

[19:18:43] <di_codes> sumanah: sure!

[19:19:54] <sumanah> di_codes: ok. so, I'm running setuptools 38.5.2

[19:20:15] <di_codes> the way I’ve been testing this is by creating a virtual env and just doing editable installs of `twine` and `setuptools` from my branches

[19:20:33] <di_codes> i.e., `pip install -e .` from the respective project root

[19:21:08] <sumanah> di_codes: yeah I thought I had done similar things. lemme try fresh just in case I did something thoughtless and forgot

[19:26:08] <sumanah> also I'm taking a moment to upgrade some globally installed packages

[19:38:15] <sumanah> di_codes: this is the error I get when I try to do that. https://hastebin.com/ufojeguneh.rb

[19:39:05] <sumanah> di_codes: I've cloned your fork of setuptools, I'm in the root of that directory, and NEVER MIND, DIFFERENT ERROR NOW.

[19:39:21] <nlh> hi sumanah

[19:39:26] <sumanah> hi nlh

[19:39:36] <nlh> hey di_codes :)

[19:40:22] <nlh> sumanah, about to try to push to your branch

[19:40:26] <sumanah> nlh: I was wondering whether we could check the assignment of some of the issues assigned to you

[19:40:32] <sumanah> nlh: ah good, cool

[19:40:33] <nlh> sure :)

[19:40:51] <sumanah> nlh: I figure a few of them maybe we could put the "help wanted/needed" label on

[19:41:15] <di_codes> sumanah: yeah, it’s `pip install -e .` not `pip install - e .` but seems like you figured that out

[19:42:09] <sumanah> like Project Description layout inconsistency #2612 and "pentadactyl hints don't work on new warehouse web interface UX/UI accessibility usability" #785

[19:42:16] <sumanah> di_codes: I did, sheepishly

[19:43:28] <nlh> yes, 2612 we could easily ask for help

[19:44:17] <nlh> 785 we could as well

[19:44:24] <nlh> (once we get a response)

[19:44:39] <nlh> if we don't get a response, this could fall under future grant applications for accessibility

[19:44:55] <nlh> e.g to do some research on plugins people are using, and make sure we are supporting them appropriately

[19:45:36] <sumanah> di_codes: I'm running some tests locally, then will try uploading something to Test PyPI. just to let you know what is up

[19:45:51] <sumanah> nlh: thumbs up. would you like to update those issues to say that, or shall I?

[19:46:05] <nlh> if you could, that would be great!

[19:46:15] <sumanah> nlh: ok. and maybe once a week we could look at what is currently assigned to you (in terms of GitHub issues) and see what we could unassign

[19:46:22] <nlh> sure :)

[19:46:27] <sumanah> seeing as we do have frontend volunteers who could help

[19:46:37] <nlh> yes, it's great that we can help with this

[19:46:53] <nlh> I'm just quite used to assigning to myself, because up until now, there hasn't been so much support

[19:47:09] <nlh> but now that this is changing, I'm happy!

[19:47:28] <nlh> *we can get help

[19:48:36] <sumanah> di_codes: when I do this and I run the twine tests for Python 2.7, "tox -e py27", I get some errors. looking now - https://hastebin.com/udixewoxac.rb in case you want to look with me

[19:49:10] <sumanah> congrats on the branch push nlh :D

[19:49:36] <nlh> haha, not that difficult when di_codes gives you all the directions ;)

[19:49:42] <nlh> thanks di_codes :)

[19:49:53] <sumanah> so I think pkginfo is part of the problem maybe

[19:50:09] <sumanah> VersionConflict: (pkginfo 1.4.1 (/home/sumanah/test/psf/twine/.tox/py27/lib/python2.7/site-packages), Requirement.parse('pkginfo>=1.4.2'))

[19:51:51] <sumanah> I have pkginfo 1.4.2 installed globally

[19:57:51] <sumanah> ok, "tox -r" (rebuilding the tox env) may have fixed it.

[19:58:04] <sumanah> it now says that pkginfo 1.4.2 is installed for the py27 env

[20:04:12] <sumanah> di_codes: readme_renderer's check gives me a warning, FYI

[20:04:12] <sumanah> $ python setup.py check -r -s

[20:04:13] <sumanah> warnings.warn(msg)

[20:04:44] <di_codes> sumanah: for what project?

[20:04:45] <sumanah> /usr/local/lib/python3.6/distutils/dist.py:261: UserWarning: Unknown distribution option: 'description_content_type'

[20:05:04] <sumanah> di_codes: ah, sorry, backing up. I have a test project at https://gitlab.com/brainwane/form990s

[20:05:23] <sumanah> https://gitlab.com/brainwane/form990s/blob/master/setup.py#L48 di_codes

[20:06:37] <sumanah> di_codes: I've been trundling along attempting to set up for a real end-to-end test

[20:07:05] <sumanah> so I added description_content_type="text/x-rst" to my setup.py

[20:23:16] <sumanah> di_codes: yay! https://test.pypi.org/project/Forms990-analysis/1.0.5.dev1/ worked, based on https://gitlab.com/brainwane/form990s/tree/markdown-support ! That's a README.md in the root of that repo, uploaded with your branches of twine and setuptools

[20:23:50] <sumanah> di_codes: so I'm going to merge your PR to Twine and I'm going to note this as code review on your setuptools PR

[20:54:10] <sumanah> waseem18: yay, trove classifier work -- thank you!

[20:55:33] <sumanah> waseem18: personally right now I am doing some volunteer work on Twine, and along the way I am learning valuable lessons about wheels, core metadata, and other packaging infrastructure topics.

[21:02:37] <sumanah> di_codes: can you walk me through your take that the DESCRIPTION.rst-making happens in `wheel` and not `setuptools`?

[21:03:02] <sumanah> di_codes: I think I don't understand where setuptools calls wheel, or I'm missing how `wheel` gets into the process

[21:05:18] <di_codes> sumanah: sure!

[21:06:01] <di_codes> this is how `wheel` hooks itself into the `setup.py` command: <https://github.com/pypa/wheel/blob/master/setup.py#L53-L55>

[21:06:45] <di_codes> so if you have `wheel` installed, and you call `python setup.py bdist_wheel`, it knows to go call that function in `wheel`

[21:07:01] <di_codes> and then it let’s `wheel` take the wheel :wink:

[21:07:38] <sumanah> aaaagh

[21:08:11] <sumanah> di_codes: thank you. I am used to looking for, you know, imports.

[21:10:57] <sumanah> di_codes: so I'm finishing up a PR to merge into twine and then I'll be making a release. if you're already filing an issue with wheel, go ahead; if you'd prefer I do it, I can try my hand at it

[21:11:45] <di_codes> sumanah: writing it now!

[21:12:41] <sumanah> and DUH re the distutils base cause of the warning /usr/local/lib/python3.6/distutils/dist.py:261: UserWarning: Unknown distribution option: 'description_content_type' . I was thinking on the wrong level and not reading the error message clearly enough

[21:19:51] <sumanah> https://github.com/pypa/readme_renderer/issues?utf8=%E2%9C%93&q=markdown we have many options for issues to reopen here too :/

[21:20:11] <sumanah> oh no, I take it back, I see now, never mind

[21:20:32] <sumanah> Dustin fixed *issue #1* on that repo!

[21:31:54] <di_codes> yeah, readme_renderer has been good to go for a long while

[21:46:26] <sumanah> jaraco: di_codes - I could use your advice. The next twine will support Metadata 2.1 & remove PyPI as a default `register` target repo (the latter being really a bugfix since PyPI wasn't taking it anyway). Point release, right? 1.10.1?

[21:47:06] <sumanah> yeah, I think I answered my own question. This is not quite enough for a feature release

[21:59:16] <sumanah> ok, probably making new twine release in about an hour

[22:06:45] <jaraco> @sumanah, I’d say any change is 0.1 bump unless it’s to fix previously intended behavior.

[22:52:31] <sumanah> jaraco: so, by default, you'd increase the minor version rather than the point version? So, v1.0.0 -> v1.1.0?

[22:53:41] <jaraco> Yes.

[22:54:08] <jaraco> Signals that there’s a meaningful, purposeful change.

[22:58:22] <sumanah> jaraco: ok. I think here we have an unusual-for-Twine case where we have a new feature within a week of a minor version release.

[22:58:35] <sumanah> Thanks for the advice!

[22:58:53] <jaraco> yw

[22:59:00] <sumanah> (invisibly to the logs ;-) )

[23:03:42] <sumanah> di_codes: I'm going to release a 1.11.0dev1 or similar thing today, and then on Monday or so, release 1.11.0 -- trying to (at least for now) follow Ian's guidance to avoid releasing Twine toward the end of a workweek

[23:37:01] <sumanah> I'm confused re: verified email as a gatekeeper on Test PyPI. I've been creating and pushing Test PyPI packages for weeks using Twine. Today I used zest.releaser and got a 400 telling me I couldn't because I had no verified email addresses.

[23:39:05] <sumanah> Oh right. We only implemented this for registering new projects and we only implemented it after I registered my most recent new project

[23:39:14] <sumanah> ok, I'm sorted out

Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Thursday the 15th of March, 2018