Log file Viewer

[02:46:53] <willingc_away> dstufft: +1 on your packaging doc comments; echo jezdez's comments :)

[08:18:48] <trash> Shouldn't it be enough do to 'git tag 0.1.0; python setup sdist' to create a proper version?

[08:19:02] <trash> It sets 0.0.0 as version in the PKG-INFO then

[08:57:19] <trash> Well, when using PBR, it does that.

[09:15:19] <doismellburning> aooh what're you using for gitmagic?

[09:15:49] <doismellburning> because I was about to write a hacky tool for setup.py to use that converted `git describe` into PEP-440 friendly things

[09:29:31] <trash> doismellburning: PBR does the versioning and changelog from a the signed git tag automatically

[09:30:42] <mgedmin> doesn't seem to be doing a very good job if you're getting 0.0.0 as the version number ;)

[09:31:25] <trash> That was before I've written "Well, when using PBR, it does that"

[09:31:48] <trash> So, if you are not using it, like I was using a simple self written setup.py with no features, it does not that.

[09:32:16] <doismellburning> trash: "that" was mildly ambiguous!

[09:32:21] <mgedmin> :)

[09:49:59] <pjdelport> I've been using hgtools for that.

[09:50:04] <pjdelport> (Versioning from tags.)

[10:16:06] <trash> yep, I see that a makefile would make sense.

[10:17:46] <doismellburning> mgedmin: what do you do about unreleased versions though?

[10:18:30] <mgedmin> doismellburning, this: https://github.com/mgedmin/profilehooks/commit/d0f02455bc38434584a97b3b07f09743100c5486

[10:19:20] <doismellburning> manual changes? right

[10:19:21] <mgedmin> release is "remove .dev0 from version, commit, tag, build sdist, upload, increase version and add .dev0, commit, push, push --tags"

[10:19:29] <mgedmin> zest.releaser can do the changes for you

[10:19:46] <mgedmin> but I haven't figured out how to teach it where I keep my version numbers when they're not in setup.py

[10:20:10] <mgedmin> I maintain a number of small projects (http://projects.gedmin.as/); 'make release' in each runs sanity checks and tells me what commands to run

[10:20:19] <mgedmin> so I can do releases even when I'm tired and have half my brain missing

[10:20:25] <mgedmin> (best decision ever)

[10:24:05] <ionelmc> mgedmin: what do you mean "when they're not in setup.py"?

[10:24:35] <mgedmin> sometimes I do things like https://github.com/mgedmin/objgraph/blob/master/setup.py#L41-L50

[11:24:33] <ronny> re

[11:24:52] <ronny> trash: you need to use setuptools_scm to do that atm

[12:28:44] <mitsuhiko> is twine still recommended for uploading packages?

[12:28:52] <mitsuhiko> the docs seem to indicate that: https://packaging.python.org/en/latest/distributing.html#upload-your-distributions

[12:31:53] <ronny> `i think so, dstufft can clarify once hes on

[12:32:06] <dstufft> mitsuhiko: yea

[12:32:20] <mitsuhiko> dstufft: why?

[12:32:25] <mitsuhiko> i thought setup.py upload does ssl now

[12:33:58] <dstufft> With Python 2.7.9 and 3.4.3 it does properly validated TLS, for every other version it's still absolutely broken, most people are not running the absolute latest versions of Python and even if they were, if anyone wants to upload binaries for 3.3, 3.2, or 2.6 then ``setup.py upload` will never be safe for those versions.

[12:34:32] <mitsuhiko> but if you upload fom 2.7.9 then you're good?

[12:36:12] <dstufft> should be yes, I didn't actually test it but it's just using urllib2 and I don't think it's doing anything that would break the new on by default validation

[12:36:39] <dstufft> It's easier to just recommend people use twine than to go into details about when setup.py upload is safe

[13:14:24] <ionelmc> what happens if you don't use twine and your wheel has dependencies?

[13:14:28] <ionelmc> dstufft: pong

[13:22:35] <ronny> ionelmc: pip downloads before inspection

[13:22:59] <ionelmc> ronny: so basically faster installs, yes?

[16:20:34] <dstufft> mitsuhiko: ping

[19:38:02] <ionelmc> one thing that irks me is that i have to manually specify the filename when i use twine upload

[19:38:25] <ionelmc> has anyone tried to integrate twine as a distutils command?

[19:51:54] <carljm> ionelmc: i think that would break part of the point of twine, which is the ability to generate an sdist, then test it, then upload that precise sdist to PyPI

[19:52:02] <carljm> (at least that's part of why I use it)

[19:52:41] <ionelmc> carljm: yeah but i want to automate my release process

[19:52:45] <carljm> specifying the filename is a necessary part of that. tab-completion makes it relatively painless

[19:53:01] <ionelmc> guessing the final filename is something that i want to seriously avoid

[19:53:45] <carljm> the filename is quite predictable. or your automation can empty out the dist/ dir first, and then rely on the sdist being the only file in the dist/ dir after setup.py sdist

[19:54:33] <ionelmc> carljm: it still feels like a dirty workaround :-)

[19:54:59] <carljm> ionelmc: of all the dirty workarounds i've seen in automated Python build and release processes, this one doesn't even register :-)

[19:55:36] <ionelmc> carljm: ok, what's the dirtiest workaround you have seen ever?

[19:55:38] <carljm> You might even be able to pull the filename out of the 'setup.py sdist' output, if you like that better.

[19:56:03] <ionelmc> without a custom sdist command? :-|

[19:56:22] <ionelmc> i wanna avoid custom commands, it's like poking the bear

[19:56:23] <carljm> i think the default output includes the filename it's writing. would have to check to be sure

[19:56:42] <carljm> ionelmc: oh i dunno, i've seen a lot of ugliness in setup.py files

[19:56:58] <ionelmc> i'm in for the beauty contest

[19:56:59] <ionelmc> heheh

[19:58:20] <ionelmc> can i override a distutils/setuptools command via entrypoints?

[19:58:51] <ionelmc> eg: i make a package that offers a fixed up `setup.py upload` or at least `setup.py twine_upload`

[19:59:01] <ionelmc> that figures out what needs uploading

[19:59:05] <ionelmc> using twine

[20:01:36] <dstufft> you can pass something like --dist-dir to ``setup.py dist``

[20:01:43] <dstufft> just pass it a temporary dir

[20:01:46] <dstufft> then twine upload that whole dir

[20:01:47] <dstufft> :D

[20:02:57] <ionelmc> dstufft: you're saying that as if glob expansion was cross-platform

[20:02:59] <ionelmc> ;-)

[20:03:29] <dstufft> ionelmc: if i recall the latest twine will do the glob expansion on windows now (I didn't implement it, but I think it does)

[20:03:38] <dstufft> gotta go pick up my daughter, bbl

[20:05:54] <ionelmc> amazing, it does!

[20:40:25] <ionelmc> mgedmin: can zest.release update multiple files with the new version?

[22:17:28] <ionelmc> dstufft: i'm baffled, i've used twine to upload a wheel on pypi but i don't see any metadata on the page

[22:17:31] <ionelmc> what's going on?

[23:09:59] <wsanchez> So I have a module that's a C extension (which is a bug, I know, but…) when I 'setup.py sdist', the resulting tarball doesn't include the headers, so then when I try to 'pip install' that, it won't compile. Adding headers to the `sources` arg to `Extension` doesn't work, so… where do I add them?

[23:12:42] <ionelmc> wsanchez try adding the headers to MANIFEST.in

[23:19:26] <wsanchez> OK, I don't have one of those, so new thing, ok.

[23:22:44] <ionelmc> wsanchez: i prefer to use grafts + excludes

[23:23:04] <ionelmc> wsanchez: https://docs.python.org/2/distutils/sourcedist.html?highlight=graft#commands