[07:50:58] <evagelos> Hello, I was advised to ask how I can contact distutils-sig@python.org to report a PyPi package (I am not familiar with mailing-lists but I just subscribed to distutils-sig@python.org
[07:51:56] <evagelos> *I was advised to ask in this channel
[08:20:12] <evagelos> I posted a thread in mailman site about it, I hope this is how it works, please let me know if you do not see it
[08:29:19] <evagelos> someone replied so it worked, thanks :)
[18:52:46] <dtux> does anyone know where this "use twine check instead" warning comes from? https://github.com/PyCQA/pylint-django/pull/217
[19:19:24] <toad_polo> dtux: Presumably you are invoking setup.py check?
[19:19:54] <dtux> toad_polo: I actually can't repro
[19:20:26] <toad_polo> Are you using the latest setuptools?
[19:30:56] <tos9> dtux: it comes from readme_renderer
[19:32:21] <tos9> and yeah switching to twine check is the right thing
[19:43:23] <tos9> dtux: twine check doesn't work the same as readme renderer (particularly it requires you to have dists), but I mass-moved all my packages to it (from readme_renderer), it works fine.
[19:43:49] <tos9> dtux: see e.g. https://github.com/Julian/jsonschema/search?q=twine+check&type=Commits
[19:47:05] <dtux> cool :) i have a "publish" env similar to your readme one in tox (top commit) that builds and runs check. but you can override the check command with {posargs} to upload instead
[19:48:40] <tos9> I have specifically avoided using tox for releases because in my opinion it's a testing tool not a release one, but that opinion is largely driven by the fact that most of my packages I am the sole maintainer of
[19:48:54] <tos9> it's a reasonable thing to do certainly
[19:49:29] <tos9> (considering there isn't a single one other tool that does it, much as there should be and ultimately will be :)
[19:50:18] <dtux> tos9: i recently adopted it... i use setuptools-scm in all my projects, and automatic deployment on tags via Travis CI. that means there's not a push-button way to publish an untagged release. this way, the check *is* a test (but it's easily overriden)
[19:52:17] <dtux> might have to steal your {envpython}... i also use {distdir} (which is flushed on the next tox invocation) instead of {envtmpdir} (which maybe is too?): https://github.com/dmtucker/backlog/blob/bd2c3bc678ffe66f308de36dde4506733148b835/tox.ini#L52-L61
[19:53:21] <tos9> dtux: right I do the autodeployment on tags
[19:53:29] <tos9> just via GH actions, and not in a way that's a single command
[19:57:01] <tos9> it kind of works/worked, but then I ran out of energy to finish it, and put it on the side
[20:05:45] <dtux> when would `python` and `{envpython}` differ?
[20:12:39] <tos9> python searches PATH, {envpython} is the one tox created in the venv for that venv
[20:12:49] <tos9> it's just always safer to use that one the same way it's safer not to activate venvs
[20:13:06] <tos9> stuff can mess with PATH, and then something ends up being not what you expected, so just good to know it's never that
[20:14:50] <tos9> I would bet {envpython} expands to python.exe on windows or whatever too, so probably "on windows" may be another reason, but none of my packages support windows for development so that I don't know / care much about