Log file Viewer

[00:32:11] <Ivo> xafer, I'd [temporarily] remove all the sphinx stuff out of it, as far as possible, and see if you can get the error to stop happening

[00:32:15] <Ivo> then add it back in

[00:32:22] <Ivo> carefully

[06:46:47] <[Tritium]> dstufft: revisit of an earlier conversation. The python 3.2 support you are removing/have removed... are you going to be doing version checks and and exiting() when python 3.2 is finally left to die, or are you just going to use language features and lett the syntaxerror propigate? Because if you just let the error happen... this solves a potential pypy3 issue.

[06:49:45] <mgedmin> afaict that's what happens

[06:50:04] <mgedmin> failures on 3.2 happen because the vendored copy of setuptools uses u'' literals

[06:50:33] <mgedmin> (there's also a UserWarning about pending deprecation of 3.2, curiously, also from setuptools)

[07:18:35] <Ivo> [Tritium], why does that make a difference?

[07:19:54] <[Tritium]> Ivo: because pypy3 reports as 3.2 but supports u"these literals, which were added in 3.3"

[07:20:13] <[Tritium]> amongst other things it supports which are newer than 3.2

[07:20:13] <Ivo> lol why would it do that

[07:20:32] <Ivo> that sounds goddamn horrible for being compatible with things

[07:20:53] <njs> there isn't really anything it can report that's "3.2 and we're working on 3.3"?

[07:21:01] <[Tritium]> it cant report being 3.3, and supporting u"" does not break 3.2 code

[07:21:36] <Ivo> well I guess as long as it says it's 3.2 then pip can't really claim to formally support it

[07:22:25] <[Tritium]> Not formally supporting it is fine, and if it breaks it breaks. but there is plenty of code in the wild that will actually check and die... and in this case, its best to let the errors happen

[07:22:29] <Ivo> why not just keep a stable 3.2 branch a in-dev 3.3 branch

[07:22:45] <[Tritium]> Ivo: I have no idea, i just use the thing

[07:22:54] <Ivo> nw

[07:23:00] <Ivo> wondering out loud

[07:23:23] <[Tritium]> my guess is they decided to make it more compatible with 2.7... which is the rational for doing it in 3.3.

[07:24:10] <Ivo> 2.7 is out for 5 years now

[07:25:01] <[Tritium]> and it will have support for about that much longer

[07:26:57] <njs> my impression is that they're barely managing to keep one py3 branch

[07:26:58] <njs> their main focus of active development is still py2, so just keeping the py3 from regressing relative to py2 requires ongoing porting etc.

[07:26:58] <njs> could be wrong, I'm not a pypy dev

[07:27:46] <[Tritium]> That is my outside impression too

[07:27:57] <[Tritium]> the branch is close to being...stale

[07:28:16] <Ivo> pypy should do a kickstarter lol

[07:28:35] <njs> Ivo: hah, uh, they've done a number of fundraisers

[07:28:50] <Ivo> but have they done a KICKSTARTER

[07:29:12] <njs> ...I don't think they've done a kickstarter

[07:29:14] <njs> or a KICKSTARTER

[07:31:53] <[Tritium]> IIRC, pypy has general funding and support from major corperations... not much, but some.

[07:35:49] <njs> [Tritium]: https://bitbucket.org/fijal/talk/src/ac373e02e58d4043efcf6d4e50f0956f989b0e16/fosdem2016/talk.rst?at=default&fileviewer=file-view-default

[07:35:52] <utek> they have some support from majro corps (like [Tritium] said)

[07:36:00] <utek> and do some pypy related consulting

[07:36:09] <utek> but it's not much

[07:36:14] <utek> so it mostly unpaid work

[07:37:01] <[Tritium]> I think i saw something in the last psf minutes about the psf paying some of their costs... and they currently have a donation drive going

[07:37:16] <[Tritium]> ...always have a donation drive going

[07:37:24] <utek> also there is some focus on vmprof

[07:37:37] <utek> I think as a part of pypy work

[07:39:29] <Ivo> dayum

[07:39:35] <Ivo> these branches

[07:39:41] <Ivo> py3.3

[07:39:44] <Ivo> py3.3-fixes

[07:39:48] <Ivo> py3.3-fixes2

[07:39:51] <Ivo> py3.3-fixes3

[07:39:56] <[Tritium]> etc

[07:40:33] <Ivo> damnit bitbucket show me when the last commit was made

[07:44:17] <[Tritium]> 22 hours ago, on 3.3

[07:44:40] <[Tritium]> 14 hours ago on the py3k branch

[07:45:11] <Ivo> would be nice if they showed a commit summary box in the source view

[07:46:37] <[Tritium]> at half an hour, its an 8th the build time of pypy!

[07:47:50] <njs> pyston doesn't even consider the idea of possibly supporting py3 yet though :-)

[07:50:36] <[Tritium]> Dropboxe's attitude as i understand it is "guido... can you get our current services working on this before you port it and our services to 3 please"

[07:51:02] <njs> guido has nothing to do with it IIUC

[07:51:24] <[Tritium]> what is he working on at dropbox? and I thought i saw him on the mailing list

[07:51:25] <njs> though they are doing a big internal static typing push in part I think in hopes of eventually leveraging it when porting to py3

[09:26:29] <mgedmin> what's with pypi?

[10:12:48] <mhils> is there any recommended approach to handle multiple, tightly coupled packages?

[10:15:11] <mhils> In our case, we have mitmproxy (mitmproxy.org) and pathod (pathod.org) as two end-user tools, who both share parts of their network stack in the netlib package. Currently we just have three repos, but the resulting workflow is quite annoying.

[10:16:45] <mhils> e.g., if we have a feature that requires changes in netlib and mitmproxy, we need two PRs, and CI will always fail for mitmproxy until the netlib PR is merged. Also, we don't run the pathod tests in this scenario, so we may break functionality without noticing it.

[10:17:26] <mhils> any good ways to handle this? (dstufft? :) )

[10:18:28] <ionelmc> mhils: use a package index for the development artifacts i'd say

[10:18:45] <ionelmc> devpi looks interesting

[10:19:28] <mhils> ionelmc: not sure how that would fix our issues?

[10:19:45] <mhils> we currently just have the three packages/repos installed in development mode.

[10:22:25] <ionelmc> what you want is basically "test A:feature-branch with B:feature-branch, where B is dep of A"

[10:22:50] <ionelmc> all while not hardcoding said branches in CI configuration

[10:23:38] <ionelmc> i think this can be formulated as "parametrize CI build with info from the PR"

[10:23:48] <ionelmc> i haven't heard of such feature

[10:24:20] <mhils> ionelmc: yes, that is one part.

[10:24:43] <mhils> another problem is that, if you work on a feature, you first have to check out the respective branches on all projects.

[10:25:20] <mhils> we do have some "multi git" stuff for that, but it's really bad for onboarding new developers.

[10:25:40] <mhils> same story for people trying to install mitmproxy from git.

[10:26:18] <mhils> ideally, we'd have everything in a single repo, but I don't see how this could work with MANIFEST.in etc :-/

[10:30:55] <ionelmc> well, if you have two repos but you don't think of them as separate projects you get these problems

[10:32:20] <ionelmc> if say, you got a project that is driven by the requirements of another project then maybe it shouldn't be separate in the first place

[10:33:09] <ionelmc> eg: if i use netifaces, how can i be sure it don't get crazy changes if all the changes are made purely for the needs of mitmproxy?

[10:33:35] <ionelmc> it's more of a process/management issue than tooling issue

[10:33:38] <ronny> mhils: see devpi?

[10:33:55] <ronny> (as in how devpi is plit into devpi, devpi client, devpi-server and they are all in a repo

[10:35:57] <mhils> ronny: thx for the pointer :)

[10:36:26] <mhils> ionelmc: so, we're just not at the point yet where we can provide a completely stable netlib API.

[10:36:52] <ionelmc> then it don't make sense to have it as a separate dep

[10:37:03] <mhils> if we wouldn't need the code for pathod, then yes, we should just include it in mitmproxy. your point has some truth in it.

[10:38:07] <ionelmc> if netifaces can't have an independent lifecycle then it shouldn't be separate

[10:39:45] <mhils> ronny: do I interpret https://bitbucket.org/hpk42/devpi/src correctly as that you just have four projects that could be separate repos in a single repo?

[10:40:15] <ionelmc> another thought: if i log a feature erquest in netifaces, and you close it because mitmproxy don't need that feature then somthing is very wrong ;)

[10:40:43] <mhils> ionelmc: netlib is just shared code between mitmproxy and pathod :)

[10:40:51] <mhils> no intention to provide anything to anyone else.

[10:42:48] <mhils> so yes, it shouldn't be separate (which is exactly why I want to change the current situation), but my question is primarly how I can combine two separate projects (mitmproxy/pathod) with shared code into a single repo.

[10:54:46] <ronny> mhils: devpi is exactly such an example

[10:55:01] <mhils> ronny: this is super helpful, thx :)

[10:55:18] <mhils> will be a bit trickier for us with travis and appveyor, but certainly doable.

[11:17:28] <Ivo> you could just put them all in the one project in different folders

[11:17:51] <Ivo> [one git project]

[11:19:10] <Ivo> dunno if you've tried doing that with git sumbodules or not

[11:19:14] <Ivo> *submodules

[22:54:42] <Ryan_Lane> howdy. is it possible to have two packages available from the same setup.py? basically I have one repo that i'd like to be able to install the server and a client from

[22:56:31] <Ryan_Lane> and to make it harder, I'd like to be able to handle editable installs from git, so like: -e git+https://github.com/lyft/confidant@master#egg=confidant and -e git+https://github.com/lyft/confidant@master#egg=confidant-client

[22:58:17] <ngoldbaum> Ryan_Lane: maybe? but that's really awful.

[22:58:31] <ngoldbaum> why not just have two packages?

[22:58:34] <ngoldbaum> shared code?

[23:01:37] <dstufft> you can't really have two packages from the asme setup.py

[23:01:49] <dstufft> but you can use #subdir to have one repo with two setup.py's (in different sub directories)

[23:01:59] <dstufft> (I think it's #subdir=foo, but not sure 100%)

[23:02:34] <Ryan_Lane> ah. ok

[23:02:37] <Ryan_Lane> yeah. I see subdir

[23:03:01] <Ryan_Lane> I'm guessing I can also use that to publish to pypi as well?

[23:04:24] <Ryan_Lane> ah. right. it's a different setup.py so obviously :)

[23:05:34] <dstufft> yea, the published package won't know anything about the original repo or that you have two things in the same repo

[23:12:35] <Ryan_Lane> cool. thanks :)

[23:20:36] <Ryan_Lane> hm. doesn't seem like you can install both eggs in the same venv, even if using subdir, though

[23:23:18] <Ryan_Lane> bah. nevermind. I'm an idiot

[23:23:19] <dstufft> your two setup.py's will need different names

[23:23:43] <Ryan_Lane> I'm using a SHA in pip line, so obviously it's going to use something old

[23:50:08] <robawt> !logs

[23:50:08] <pmxbot> http://chat-logs.dcpython.org/channel/pypa