pmxbot IRC Log Viewer

[00:11:01] <lifeless> dstufft: nuts, I've lost your specs for pbr for pip

[00:11:07] <lifeless> dstufft: I have https://github.com/pypa/pip/issues/2312

[00:13:13] <dstufft> lifeless: resent

[00:13:42] <lifeless> dstufft: sweet, thanks. I would have found it eventually but you saved me a chunk f time :)

[00:21:35] <dstufft> lifeless: no problem :D

[02:22:23] <lifeless> dstufft: q for you

[02:22:30] <lifeless> dstufft: why do you think pbr needs entry point templating

[02:22:32] <lifeless> dstufft: like

[02:22:38] <lifeless> dstufft: could that just be in setup.py ?

[02:22:58] <lifeless> dstufft: doing it right needs wheel and setuptools collaboration

[02:23:25] <lifeless> dstufft: we could do it there and then embed setuptools

[02:23:36] <dstufft> lifeless: oh, I just assumed that pbr took over the entire setup.py

[02:23:39] <lifeless> but just making the default wheel for pip python minor version specific

[02:23:50] <lifeless> should be enough

[02:23:52] <dstufft> so

[02:23:59] <dstufft> wheels don't include entry points by default

[02:24:05] <dstufft> and pip has special cased logic for pip

[02:24:16] <lifeless> right

[02:24:17] <dstufft> to enable the version specific commands

[02:24:32] <dstufft> if I can pass the entry points in the setup.py as we do now, that's fine

[02:25:22] <sigmavirus24> Is pip switching to pbr?

[02:25:34] <lifeless> dstufft: we may need to make sure it merges them

[02:25:42] <lifeless> dstufft: but thats fairly minor

[02:26:21] <dstufft> sigmavirus24: I want to automate pip's release process, a (big) part of that is automating the version number

[02:26:39] <dstufft> lifeless wanted to know awhile back what our requirements would be to use pbr for it instead of inventing a one off tool

[02:27:10] <dstufft> so the answer to that is, "maybe", if lifeless can sort out how to make pbr work the way we need :D

[02:28:10] <dstufft> the biggest sticking point (I think) is that we don't want pbr to be a requirement in the released tarballs, but we're OK with it in development checkouts

[02:29:31] <lifeless> dstufft: see whether https://review.openstack.org/218062 grabs you

[02:29:50] <lifeless> dstufft: ChangeLog is already disableable

[02:29:58] <lifeless> dstufft: though the docs on doing that are atrocious (missing)

[02:30:16] <lifeless> [pbr]

[02:30:22] <lifeless> skip_changelog=True

[02:30:32] <dstufft> lifeless: reading now, and cool. I wasn't sure so made sure to mention it

[02:30:48] <lifeless> dstufft: there's a thing we're doing for *release notes* which I think matches what pip wants

[02:31:02] <lifeless> but I've pushed for that to be an independent thing-for-git-projects

[02:31:23] <lifeless> so modulo semver version calculations its independent and we can use for JS ec

[02:31:25] <lifeless> etc

[02:31:44] <lifeless> we'll need to pull those out to a helper library and vendor that back to pbr, but thats still less than all-of-pbr

[02:32:37] <lifeless> Nakato: tchaypo: ^ may be of interest to you too - its lower pri than finishing the current arcs, but useful to be aware of

[02:33:40] <lifeless> now, what was the other spec I needed to write. Oh yeah, testr-outside-tox

[02:34:48] <lifeless> dstufft: the embedding bit I haven't actually tested-in-detail

[02:34:50] <dstufft> lifeless: oh, it needs to write the version into a file inside of the installed distribution, like pip/_version.json or something, so we can get the version of the code that's actually running not what version pkg_resources thinks is installed

[02:34:58] <lifeless> dstufft: but I'm fairly sure its at most nibbly

[02:35:15] <lifeless> dstufft: hmm, we can do that, but I don't understand why

[02:35:36] <lifeless> dstufft: since we already write that in metadata files which the vendored pkg resources can read

[02:35:51] <dstufft> lifeless: pip gets run in situations that it's not installed, so we can't depend on installation metadata for a version number

[02:36:17] <lifeless> dstufft: I'm fairly sure the egg info in . in that case is used

[02:36:55] <lifeless> dstufft: but - lets assume its not. Could we manually find and read that, or do people mess with the tree in invasive ways ?

[02:37:08] <lifeless> not egg-info

[02:37:11] <lifeless> dist info

[02:37:12] <lifeless> thingt

[02:40:07] <dstufft> lifeless: I'm not sure that the egg-info or dist-info exists in all of those situations.. it might but I'm not actually sure

[02:41:15] <lifeless> dstufft: pbr-1.5.1.dev3$ ls

[02:41:18] <lifeless> ..

[02:41:20] <lifeless> pbr.egg-info

[02:41:34] <lifeless> (freshly unpacked sdist)

[02:42:02] <dstufft> lifeless: sorry, I mean in the situations where people do something like stick pip/ in a zip file or such.

[02:42:03] <lifeless> I'm not averse to writing a new file, but I would like to understand why

[02:42:14] <lifeless> oh

[02:42:22] <lifeless> so I can imagine many ways folk can break stuff

[02:42:32] <lifeless> like - they can also break it by not including this new json file

[02:43:02] <dstufft> right, but it's less likely they'll delete a file from inside of pip/ then a diretory alongside that

[02:43:21] <lifeless> I make no assumptions about users :)

[02:43:45] <lifeless> anyhoo

[02:43:48] <lifeless> if thats the only thing

[02:44:14] <lifeless> we can add a local sdist hook in the pip tree to start with I think

[02:44:20] <lifeless> layer that on

[02:46:50] <dstufft> lifeless: that works for me

[02:47:22] <lifeless> I think it would make sense to use the egg info and file bugs wherever it not usable

[02:47:31] <lifeless> e.g. issue a UserWarning and fallback to this other thing

[02:47:31] <dstufft> lifeless: to be clear, I don't so much care if every single feature lands in pbr or not, mostly that it's possible to have it work in pip that way without pbr getting in the way of it happening

[02:47:39] <lifeless> yeah

[02:47:42] <lifeless> so

[02:47:48] <lifeless> we'll see what discussion that spec gets

[02:48:27] <dstufft> I agree that I think an embedded pbr (or some static subset of it) should work acceptably

[02:51:26] <lifeless> cool

[02:52:21] <dstufft> might be useful to get the guy who does pip's packaging in Debian (Barry Warsaw) to weigh in on the plan to make sure it's not going to make things super hard for him

[02:52:37] <dstufft> I can poke him and ask

[02:53:24] <dstufft> I'm not sure if a bundled copy of pbr just for executing setup.py counts for Debian's "no bundling" policy or not

[02:53:50] <lifeless> dstufft: if it doesn't get into the final package, it won't

[02:53:58] <dstufft> oh right

[02:54:01] <lifeless> dstufft: we don't reject things that have configure in them, for instance.

[02:54:01] <dstufft> you're a DD

[02:54:02] <dstufft> you know the rules

[02:54:05] <dstufft> :D

[02:54:19] <lifeless> it may make him go ewwwwww

[02:54:26] <lifeless> but thats why it will be an opt-in feature in pbr

[02:54:40] <dstufft> he's pretty understanding about pip's bundling

[02:57:18] <lifeless> dstufft: btw https://review.openstack.org/#/c/217528/

[02:58:14] <dstufft> lifeless: awesome, thanks! And Nakato too :)

[03:35:43] <lifeless> ok, plane 2 :)

Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Friday the 28th of August, 2015