Log file Viewer

[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? 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:39:01] <dtux> toad_polo: yes

[19:39:08] <dtux> tos9: aha! havent checked there yet, ty

[19:40:52] <dtux> nice: github.com/pypa/readme_renderer/blob/2c42c8ef564a421ab4f3193797d2c7214c6ca6a1/readme_renderer/integration/distutils.py#L69

[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. 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?): 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:53:47] <tos9> github.com/Julian/jsonschema/blob/master/.github/workflows/packaging.yml

[19:54:08] <dtux> oh... wow. brain fart... ya i've switched to GH actions for personal stuff. that was a driving motivator for the publish env

[19:54:14] <tos9> it's the same difference, but ultimately some day I'll have it be `war release .` which will just perform those exact steps

[19:54:28] <dtux> github.com/dmtucker/backlog/blob/master/.github/workflows/publish.yml

[19:54:40] <dtux> ooo `war`?

[19:55:32] <dtux> (forgot about GH actions because it isnt available for enterprise yet, so we still use travis at work)

[19:56:12] <tos9> dtux: war is a thing I started and then stopped writing whose goal is "wrap the packaging tools you already use"

[19:56:25] <tos9> i.e. `war upload .` just simply runs `twine upload .`

[19:56:30] <tos9> `war install .` just runs `pip install .`

[19:56:40] <tos9> `war release .` runs those commands, etc.

[19:56:54] <dtux> ah, twine + pip

[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

[20:14:54] <tos9> (you might though)

[20:15:34] <dtux> ya, i figured it was just cautious. the whole whitelist_externals req probably helps with that alot... ya, no win here