Log file Viewer

[18:37:47] <tdsmith> dstufft: should --single-version-externally-managed influence INSTALLER?

[19:55:01] <glyph> tdsmith: AAUGH THE NIGHTMARE NEVER ENDS

[19:55:08] <glyph> why is --single-version-externally-managed still a thing?

[19:57:18] <dstufft> tdsmith: nothing should influence it except someone explicitly passing in a new value

[19:58:32] <dstufft> glyph: are you asking for real

[19:58:36] <dstufft> because lol

[19:58:49] <dstufft> basically it's a thing, because setuptools still has multi version installs as a feature

[19:59:16] <dstufft> and you can't get rid of -svem without getting rid of multi version installs

[20:00:02] <dstufft> setuptools is far less willing to break things than I am

[20:11:51] <glyph> we should call it "single install / global hierarchy"

[20:11:57] <glyph> so the option can just be --sigh

[20:12:21] <glyph> dstufft: thanks for the explanation.

[20:20:24] <elarson> !m glyph

[20:20:24] <pmxbot> you're doing good work, glyph!

[20:21:47] <elarson> glyph: that has made my day, which is something b/c I've been fighting dh-virtualenv and pbr

[20:22:04] <glyph> death to pbr :(

[20:25:16] <elarson> man seriously

[21:16:00] <nedbat> glyph: i don't like pbr, but just by prejudice, i don't know much about what it does. What does it do that has set you against it?

[21:57:41] <glyph> nedbat: Good question! There's one issue in particular: https://github.com/testing-cabal/testtools/issues/139

[21:58:09] <glyph> nedbat: But generally the attitude of the maintainers is that no environment but a virtualenv on Linux matters.

[21:58:21] <nedbat> glyph: yikes

[21:58:37] <glyph> nedbat: Rob is _correct_ on that issue, in that the bug is really in py2app

[21:58:44] <glyph> nedbat: technically correct! the best kind of correct

[21:59:16] <glyph> nedbat: but the point is that the setuptools ecosystem is still remarkably fragile, especially when you depend extensively on its APIs at runtime

[21:59:42] <nedbat> and pbr depends on the api?

[21:59:51] <glyph> nedbat: in this case it's depending on something in Python (the 'site' module)

[22:00:45] <glyph> nedbat: but the value that pbr provides is so miniscule as to be impossible to describe

[22:01:25] <nedbat> glyph: yeah, i don't like tools that help you avoid writing setup.py. they generally introduce complexity and magic.

[22:01:37] <glyph> nedbat: so the fact that it has catastrophic knock-on effects like "mac apps don't work" or "you can't build a self-contained executable using any existing tools" is a giant bummer.

[22:04:52] <glyph> nedbat: rob's defense is of course that all the tools that do that kind of packaging are horribly buggy, which is a true, but not useful, statement :)

[22:26:11] <dstufft> glyph: I want something that does part of what pbr does

[22:26:15] <dstufft> but like, only in a git repo

[22:26:31] <dstufft> when I make a sdist it should be all self contained

[22:29:15] <glyph> dstufft: what exactly does it do?

[22:29:42] <glyph> dstufft: its readme just says it was some ... stuff that people used to copy and paste a lot in OpenStack, which isn't a description of functionality

[22:31:54] <dstufft> glyph: well it does a number of things, one of the things I'm most interested in is that is can generate a version from git history

[22:32:06] <dstufft> so you don't need things like "bump for X.Y+1"

[22:32:09] <dstufft> commit slike ^

[22:33:20] <dstufft> it does some other stuff, like try to move the metadata to a static location (but not really, because we all still execute setup.py, it just adds extra code in the path to getting the metadata), automatically running find_packages based on git stuff

[22:33:31] <dstufft> autogenerate AUTHORS file based on git log

[22:33:36] <dstufft> autogenerate changelog based on git log

[22:33:42] <dstufft> mostly I want the version thing though.

[23:16:32] <nedbat> dstufft: i would think git-log --> changelog would be kind of bad.

[23:16:43] <dstufft> it depends

[23:17:06] <nedbat> dstufft: i think the people that can write git logs that would become changelogs are also the kind of people that can maintain a changelog.

[23:17:29] <dstufft> it works OK for openstack, because every change they make goes through gerrit, and there are no intermediate commits so it's a squash merge and their gerrit system also lets them review commit messages as part of the thing

[23:17:56] <nedbat> dstufft: can they sort the messages into "New features" "breaking", etc?

[23:18:38] <dstufft> yea, they have headers they can put in the commit message I Think (and their auto magic versioning also parses those headers to determine if it needs to do a major, minor, or micro release bump)

[23:18:43] <dstufft> I don't like it much

[23:19:33] <dstufft> I don't do squash merges, so it's right out for me there, and I don't think every single change deserves a mention in the changelog, and I also don't like that it's impossible to edit the change log entry without rewriting history

[23:20:02] <dstufft> but the problem it solves is a real one with your standard changelog file, if you have two people trying to land changes at the same time, there's a good chance their changelog commit is going to conflict

[23:20:12] <dstufft> I like Twisted's solution to that problem better

[23:23:41] <nedbat> dstufft: which is?

[23:24:24] <dstufft> https://github.com/hawkowl/towncrier is the Twisted system reimplemented as as tanda lone project

[23:24:29] <nedbat> dstufft: my solution to the conflict problem was to tell developers, "don't always put your message at the top, just put it somewhere near the top," but the uncertainty of that drove some of them crazy

[23:25:05] <dstufft> but basically: instead of one change log entry in the same file for every change, you have a directory and each change adds it's own file containing 1 entry to the changelog

[23:25:26] <dstufft> during the release process all those entries in that directory are compiled into a singular, traditional changelog

[23:25:54] <nedbat> cool

[23:26:47] <nedbat> i like it

[23:27:19] <nedbat> not sure about file extensions of .feature, etc, but close enough

[23:28:19] <dstufft> yea, it's a trade off, twisted (and I Assume towncrier does) formats different "kinds" of changes differently in the final log so it needs to know what kind of change it is

[23:28:38] <dstufft> https://github.com/hawkowl/towncrier/blob/master/NEWS.rst

[23:28:40] <dstufft> shows it

[23:28:46] <dstufft> new features at the top, then bug fixes, etc

[23:28:47] <nedbat> dstufft: ok, but why not: 850.feature.rst ?

[23:29:07] <dstufft> probably just historical baggage from twisted's topfiles

[23:29:32] <nedbat> ok. gotta jet, thanks for showing it to me :)

[23:37:31] <dstufft> nedbat: no problem :]