pmxbot IRC Log Viewer

[01:19:26] <agronholm> setuptools looks like it's adopted a versioning scheme like that of firefox and chrome

[01:21:11] <agronholm> bumping major versions for no real reason that

[01:21:20] <agronholm> *that is

[01:21:43] <agronholm> how are we supposed to tell when breaking changes occur?

[09:24:18] <Ivo> agronholm: if you were worried I'd say make an issue on bitbucket

[09:24:24] <Ivo> might be a good thing to consider

[10:07:53] <Ivo> dstufft, pf_moore aware of any continuous integration for setuptools?

[10:11:35] <pf_moore> Ivo: Nope, no idea, sorry.

[10:15:57] <Ivo> pf_moore: I get the feeling, no.. :/

[10:23:56] <pf_moore> Ivo: yeah, there isn't anything like travis for bitbucket AFAIK

[10:24:18] <Ivo> foo github monoculture

[10:24:31] <Ivo> man need jaraco back, setuptools borked a lot of ppl again :/

[10:25:43] <Ivo> pypi setuptools release also has a bus factor of 1 atm, unless you maange to get in contact with ian :/

[10:42:57] <agronholm> bus factor?

[10:48:48] <Ivo> !w bus factor

[10:48:49] <pmxbot> Ouch! An error occurred: No weather for bus factor; Google weather APIs disabled

[10:48:49] <pmxbot> !w Get weather for a place. All offices with "all", or a list of places separated by pipes.

[10:48:55] <Ivo> !wiki bus factor

[10:49:04] <Ivo> agronholm: https://en.wikipedia.org/wiki/Bus_factor

[11:16:35] <Ivo> yo jaraco

[11:16:53] <Ivo> wanna do a 4.0.1 with https://bitbucket.org/pypa/setuptools/issue/213/regression-setuptools-37-installation#comment-10490974

[11:20:45] <pthiem> "jaraco, just saw the note on 193

[11:21:00] <pthiem> lol

[11:22:36] <Ivo> pthiem: you can always pass 'ignore' to .encode() 2nd arg to make it less fragile :D

[11:23:35] <pthiem> where at?

[11:25:19] <Ivo> pthiem: your write_file issue

[11:27:12] <pthiem> the code in the bug wasn't the final code.

[11:27:40] <pthiem> well hmm

[11:29:23] <Ivo> jaraco: also trialing a CI server that works with bitbucket for setuptools, you might get an email on it

[11:30:06] <dstufft> setuptools has a mirror on github for travis integration afalk

[11:30:10] <dstufft> afaik*

[11:30:29] <Ivo> war

[11:30:33] <Ivo> *where

[11:30:38] <pthiem> yeah jataco uses hg-git

[11:31:36] <Ivo> aha...

[11:31:39] <Ivo> https://travis-ci.org/jaraco/setuptools

[11:31:47] <Ivo> seems tests couldnt pick up on the current regression

[11:31:58] <dstufft> it doesn't appear that it's up to date though

[11:32:02] <dstufft> last commit was May 8?

[11:32:07] <pthiem> ivo, yeah in the case of the manifest everything should be utf-8 encodable, but the are a couple other things in write_file outputs

[11:32:37] <pthiem> (should be = have already been weeded out)

[11:32:54] <Ivo> dstufft: i see last commit as 15 hours ago

[11:32:56] <dstufft> wat

[11:33:01] <Ivo> last build 14 hours ago

[11:33:08] <Ivo> https://travis-ci.org/jaraco/setuptools/jobs/26529433

[11:33:10] <dstufft> http://d.stufft.io/image/2h3U0d0i3W1t

[11:33:51] <Ivo> dstufft: try https://github.com/jaraco/setuptools/commits/master lol

[11:34:05] <dstufft> welp

[11:34:07] <dstufft> software

[11:34:22] <pthiem> he doesn't work off git, afaik

[11:35:30] <Ivo> if hg had nice lightweight named commit-dag'ed branches, i would welcome it into my heart

[11:36:23] <dstufft> Ivo: bookmarks?

[11:37:05] <Ivo> does bitbucket work with them?

[11:37:10] <dstufft> define works

[11:37:17] <dstufft> setuptools uses them

[11:37:34] <dstufft> but bitbucket kind of gets funky with them sometimes I think

[11:37:38] <Ivo> does-PRs-super-nicely-with-them-like-how-github-does-with-branches

[11:37:44] <dstufft> dunno about that

[11:37:52] <dstufft> I don't like Hg so I don't know a lot about it

[11:38:25] <pthiem> ivo: it at least recognizes them, though I seems that I have to identify them by hash

[11:38:27] <Ivo> we need less hg-for-svn-developers and more hg-for-git-developers

[11:38:32] <dstufft> (infact I dislike hg enough instead of trying to use branches, I just store multiple patch files and I use patch to apply them to "switch" branches

[11:41:04] <Ivo> does travis have post-build hooks?

[11:41:31] <Ivo> oh in travis.yml

[11:41:37] <pthiem> yeah

[11:41:51] <Ivo> jaraco: you accept PRs to setuptools over github?

[12:03:32] <jaraco> Ivo, sure

[12:06:00] <pthiem> ahh hey there he is :D

[12:07:01] <pthiem> jaraco, I was taking a look at that regressions you mentioned

[12:09:37] <jaraco> pthiem, Glad to hear it. To be sure, I'm not blaming your PR or work on 3.7. It's quite possible, likely even, that I made changes to your PR that were implicated.

[12:09:43] <Ivo> jaraco: is there a particular reason you include setuptools.egg-info/ under version control?

[12:10:24] <jaraco> Ivo, it's because setuptools can't build without having setuptools present (and its entry points).

[12:10:49] <jaraco> So without having them in the source code, a virgin Python can't install setuptools from the repo.

[12:11:14] <Ivo> jaraco: it can't install itself with distutils?

[12:11:25] <jaraco> It cannot.

[12:12:01] <Ivo> is there a particular really-annoying reason it can't that you know?

[12:13:14] <dstufft> it uses dependency_links at least

[12:13:16] <agronholm> jaraco: what's with the crazy version numbering? did something major happen in 4.0?

[12:13:52] <agronholm> setuptools looks like it gets a .1 bump for every commit

[12:14:35] <jaraco> agronholm, it's semver

[12:14:37] <jaraco> !g semver

[12:14:37] <pmxbot> http://semver.org/ - Semantic Versioning 2.0.0

[12:15:06] <agronholm> so API incompatible changes were made?

[12:15:44] <jaraco> 4.0 removed an expectation about how scripts are installed by setup.py develop. If someone depended on the behavior to copy the files as text, this change would violate that expectation.

[12:15:57] <agronholm> I see

[12:16:41] <agronholm> I myself also try to follow the semantic versioning thing

[12:16:46] <jaraco> It's a subtle change, and potentially could have been considered a bugfix or simple enhancement... but it felt more like a contractual change to me (though small).

[12:17:24] <agronholm> it still feels like setuptools is getting releases a bit too often

[12:17:33] <Ivo> setuptools supposed to run on python 3.1 any more?

[12:17:42] <agronholm> does anyone care? :)

[12:17:51] <jaraco> Ivo, yes

[12:18:02] <jaraco> agronholm, what's the downside to too often?

[12:18:11] <dstufft> jaraco: it becomes hard to keep up :]

[12:18:16] <agronholm> that

[12:18:38] <jaraco> if the releases are too frequent to keep up, then only bump releases as time permits.

[12:18:45] <jaraco> Allow several releases before keeping up.

[12:18:46] <Ivo> people are not used to seeing so many major and minor versions coming out for something so 'core', to put it in words

[12:19:20] <jaraco> Frequent releases give more control, not less.

[12:19:24] <Ivo> probably not used to such a strict following of semver while doing releases often

[12:19:50] <dstufft> jaraco: eh, not really, because it's near impossible to actually pin to a specific version of setuptools ;(

[12:19:51] <Ivo> I'm just stating the observation why, incase it wasn't obvious

[12:20:03] <dstufft> I know openstack has tried tod o it in the past in their gate

[12:20:05] <Ivo> that's a good irk as well

[12:20:08] <dstufft> and it just broke things

[12:20:58] <pf_moore> virtualenv 1.11.6 bundles setuptools 3.6 which "feels old". I know it's just a pip install -U away, but hey.

[12:21:41] <dstufft> jaraco: FWIW I'm not one to tell you how to run setuptools or anything :) just saying that it's a problem with frequent releases, the flipside to infrequent releases is that stuff gets locked away fixed/added but unreleased for some period of time

[12:21:42] <agronholm> also, you probably wouldn't have to bump the major version so often if you consolidates API breaking changes over a longer time period

[12:21:51] <agronholm> *consolidated

[12:22:53] <Ivo> 3.6 doesn't feel old to me >_>

[12:23:07] <dstufft> Python 3.4 is on 2.1 IIRC

[12:23:10] <dstufft> :|

[12:23:10] <jaraco> agronholm, but then every client would have to absorb all breaking changes at once. Having multiple releases means each client has control over which breaking releases to accept and when.

[12:23:17] <pf_moore> when 4.x is out...

[12:23:37] <pf_moore> My understanding of semver is that API-breaking changes are bundled up to make a major releases

[12:23:45] <Ivo> 4.x isn't nearly as different to 2.x as 2.x is to 0.x though

[12:23:55] <jaraco> Right. So if we're using semver, we have to shake the perception that a major version bump means a lot of changes. It doesn't mean that at all, but only means that some contract was broken since 3.x.

[12:24:23] <dstufft> well semver states that any breaking change is bumped, although I think in practice that tends to mean changes are bundled together like that for a lot of projects, it doesn't have to mean that

[12:24:24] <agronholm> jaraco: then clients have to adapt so many times

[12:24:37] <pf_moore> Yeah, but doesn't it *also* mean that upgrades through a major version carry a risk?

[12:24:47] <agronholm> yep

[12:24:49] <agronholm> "If even the tiniest backwards incompatible changes to the public API require a major version bump, won't I end up at version 42.0.0 very rapidly?"

[12:24:54] <agronholm> "This is a question of responsible development and foresight. Incompatible changes should not be introduced lightly to software that has a lot of dependent code. The cost that must be incurred to upgrade can be significant. Having to bump major versions to release incompatible changes means you'll think through the impact of your changes, and evaluate the cost/benefit ratio involved."

[12:25:01] <jaraco> dstufft, that's a consideration I hadn't made. I presumed, perhaps incorrectly, that most systems did not upgrade to the latest automatically. By adopting semver, setuptools declares that it expects its users to give deference to that adoption.

[12:25:07] <agronholm> ^ from semver FAQ

[12:25:39] <pf_moore> Also, if you don't bundle major changes, people lose access to bugfix changes over a major release

[12:26:01] <agronholm> jaraco: are you going to do any 3.x setuptools releases?

[12:26:03] <jaraco> agronholm, I don't see any problem with version 42.0.0. It's a bit more to type, but negligibly so.

[12:26:03] <pf_moore> That's less friendly for users who want to only auto-update painless releases

[12:26:34] <dstufft> jaraco: setuptools and ensurepip pin to a specific setuptools version, so if they are using a virtual environment they'll at least start out with a particular version, but it's not unusual for something to trigger it to get updated

[12:26:40] <agronholm> or do I have to upgrade to 4.x to get bugfixes

[12:27:19] <jaraco> pf_moore, people _can_ lose access to bugfix changes as necessary. And the same is true for 0.x releases as well, no?

[12:28:01] <agronholm> that made no sense to me

[12:28:11] <pf_moore> glad it's not just me :-)

[12:28:15] <jaraco> agronholm, you're right, I mis-edited.

[12:28:27] <jaraco> I meant to say bug fixes can be back-ported as necessary.

[12:28:49] <pf_moore> OK, but there's no process of doing so ATM, is that right?

[12:28:52] <agronholm> if they WILL be backported to lower major versions, then it's not such a big problem

[12:28:58] <pf_moore> It's possible to argue (not that I am) that Python 3.4 should bundle setuptools 2.x only because going to 3.x or 4.x breaks Python's compatibility requirements.

[12:28:59] <jaraco> And if there are essential fixes (i.e. security fixes) that need to be back-ported to 1.x, I still plan to support that.

[12:29:05] <dstufft> jaraco: it's also true that most people don't have control over what their end users have installed, so more "breaking" versions means a larger matrix of backwards incompat versions to test (or at least be aware of)

[12:29:37] <dstufft> pf_moore: pip/setuptools are exempt from that

[12:30:17] <pf_moore> dstufft: I know (hence I wasn't suggesting it) but it's an easy example of how setuptools' versioning impacts what other tools can bundle.

[12:30:37] <Ivo> jaraco: have some github PRs

[12:30:44] <pf_moore> If virtualenv had strict compatibility rule like Python, we'd have the same question there with 1.11.x

[12:30:55] <jaraco> dstufft, the alternative is not to fix issues that have backward-compatible releases or to implement those changes but not declare the compatibility concerns, which is what most other projects do.

[12:31:19] <jaraco> (not declare the compatibility concerns using semver, I mean)

[12:33:58] <dstufft> jaraco: you mean backwards incompatible?

[12:34:23] <jaraco> dstufft, yes

[12:35:04] <pthiem> ivo: looks like travis failed

[12:35:39] <dstufft> jaraco: sure, I mean you can also hold off on backwards incompat changes until you have a couple of them to bundle together. It's a larger pain, but it's condensed to one episode instead of multiple episodes

[12:36:06] <dstufft> jaraco: FWIW I think you should do setuptools however you think is appropiate, so please don't feel like i'm trying to tell you how to run it :)

[12:36:50] <dstufft> jaraco: I do know that i've gotten some feedback (particular from openstack) where they are feeling somewhat exasperated about how frequently setuptools is released (or more specifically, how frequently setuptools is released that breaks something for them)

[12:37:16] <Ivo> pthiem: no idea how that error occurred.. but it occured with pypy somewhere completely random -_-

[12:37:34] <jaraco> dstufft, In my defense, I did release a beta release of 3.7 with a tweeted announcement.

[12:37:46] <dstufft> jaraco: I also think this is _really_ hard to figure out what's going to break things for people, becuase of the nature of the situation where you have distutils, then setuptools layered on top of it and then pip on top of that

[12:38:15] <dstufft> and none of the boundaries between those things are particularly well defined :(

[12:38:23] <jaraco> Sometimes, it seems the only way to get feedback is to release and await feedback, and then try to respond quickly.

[12:38:36] <pthiem> ivo: yeah it's weird

[12:38:51] <dstufft> jaraco: oh I agree, In my experience pip gets almost zero feedback from pre-releases

[12:39:08] <Ivo> Alex_Gaynor: you ever see zipimport errors with pypy?

[12:39:52] <Ivo> https://travis-ci.org/jaraco/setuptools/jobs/26569049#L901-L906

[12:40:48] <dstufft> jaraco: I don't actually know what the right answer is or anything :) I just am more or less parroting what i've seen a few people describe recently

[12:40:56] <pthiem> jaraco, maybe some of the zipcach stuff added post 3.7?

[12:41:11] <pthiem> (wrt to the error above)

[12:41:13] <dstufft> plus adding some stuff about where problems may exist!

[12:42:00] <jaraco> pthiem, Does appear related to zip-cache work added for 4.1 but not yet released.

[12:43:02] <pthiem> ivo, yeah its probably in flux atm. pypy is *not* compatible with cpython wrt to the zipcache

[12:43:53] <Ivo> maybe rebase aginst 4.0 then

[12:45:32] <Ivo> atm ppl who upgrade to setuptools 4.0 won't be able to install any pbr-based projects on py2 it seems

[12:46:23] <jaraco> Ivo, or setuptools >=3.7b1

[12:46:40] <Ivo> or a 3.X, yeah

[12:47:03] <dstufft> openstack fixed their CI just now by blacklisting setuptools 3.7+ from their mirror (they don't install from PyPI in their CI) but it's stil broken on folk's laptops and such

[12:54:26] <pthiem> jararco, actually i'm not sure how unicode from the file list would be migrating to the requirements. I could try to bisect it there (have work), but there are some simple patches which paport to fix the issue.

[12:57:52] <pmxbot> jaraco pushed 6 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :

[12:57:52] <pmxbot> Use compat's StringIO. Should fix bitbucket #213

[12:57:52] <pmxbot> Move tests.sh to a tox config

[12:57:52] <pmxbot> Ignore the tox folder

[12:57:52] <pmxbot> Merge pull request #7 from Ivoz/fix-213

[12:57:52] <pmxbot> Merge pull request #6 from Ivoz/toxify

[12:57:52] <pmxbot> Use compat's StringIO. Should fix bitbucket #213

[13:03:28] <pmxbot> jaraco pushed 4 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :

[13:03:28] <pmxbot> Bumped to 3.7.1 in preparation for next release.

[13:03:28] <pmxbot> Update changelog

[13:03:28] <pmxbot> Added tag 3.7.1 for changeset 9b422fc0b8b9

[13:03:28] <pmxbot> Bumped to 3.7.2 in preparation for next release.

[13:05:47] <Ivo> pthiem: huh, and now the pypy build works

[13:06:20] <pthiem> ivo, without rebasing?

[13:06:24] <jaraco> Ivo, that's because I grafted your change onto 3.7 (preceeding the pypy breaking change)

[13:06:33] <Ivo> ohh

[13:06:37] <pthiem> aha there :)

[13:06:45] <pmxbot> jaraco pushed 1 commit to setuptools (https://bitbucket.org/pypa/setuptools/) :

[13:06:45] <pmxbot> Merge with 3.7.1

[13:07:47] <pmxbot> jaraco pushed 3 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :

[13:07:47] <pmxbot> Bumped to 4.0.1 in preparation for next release.

[13:07:47] <pmxbot> Added tag 4.0.1 for changeset b14a51112acf

[13:07:47] <pmxbot> Bumped to 4.0.2 in preparation for next release.

[13:09:10] <pthiem> Aah write_requirements was changed

[13:09:20] <pmxbot> jaraco pushed 1 commit to setuptools (https://bitbucket.org/pypa/setuptools/) :

[13:09:20] <pmxbot> Merge with 4.0.1

[13:09:44] <Ivo> I'll never understand why some people think unicode under py2 is easy

[13:10:35] <jaraco> okay - 3.7.1 and 4.0.1 released with the fix

[13:10:38] <pthiem> well its "easier" if you can ensure everything is actually unicode

[13:10:51] <pthiem> instead of str/unicode mix :/ but yeah

[13:11:40] <Ivo> jaraco: I was thinking currently setuptools is only uploadable by you and ian bicking.. is that a big enough bus factor?

[13:12:08] <jaraco> no

[13:12:50] <Ivo> might consider adding dstuff andor jezdez as maintainers

[13:16:52] <pthiem> 71d2935,

[13:16:53] <pthiem> f2b81e9

[13:17:02] <pthiem> oops mistype there

[13:18:13] <pthiem> jaraco, my guess was the changes are introduces at (71d2935, f2b81e9, 3d98c27)

[13:18:21] <Ivo> btw jaraco I don't envy your position of getting to be the guy that has to release setuptools, good work :)

[13:18:24] <jaraco> done

[13:19:06] <pthiem> ty :)

[13:19:28] <Ivo> dhellmann: you might have noticed ppl complaining about a setuptools bug relating to pdb which broke virtualenvwrapper, you might consider uploading a wheel for it which would fix that in the future :)

[13:19:51] <dhellmann> Ivo: I was going to offer to help add tests to setuptools, actually

[13:20:09] <Ivo> dhellmann: I'll take that any day of the week

[13:20:25] <dhellmann> is there a test suite that tries installing packages? I'm looking at https://github.com/jaraco/setuptools/tree/master/tests and don't see much

[13:20:29] <dhellmann> is that the right place to look?

[13:20:39] <dhellmann> ah, I see more in https://github.com/jaraco/setuptools/tree/master/setuptools/tests

[13:20:46] <Ivo> I suspect adding some really-unicode-using package to test installing might help with regressions

[13:20:53] <dstufft> also

[13:21:07] <dstufft> bitbucket's emails are terribad

[13:21:09] <jaraco> dhellmann, the canonical tests are run using travis; see .travis.yml for the canonical test invocation.

[13:21:16] <dhellmann> afaik, none of the packages bit by this issue were "unicody" in any particular way

[13:21:22] <dhellmann> jaraco: cool

[13:21:28] <Ivo> dstufft: any type of emails in particular?

[13:21:39] <dstufft> Ivo: the ones where it says "so and so did a thing on this ticket"

[13:21:42] <dstufft> they reuse the same message id

[13:21:50] <dstufft> so mail.app collapses it into the old message

[13:21:55] <dstufft> even though the content is the same

[13:22:26] <jaraco> dhellmann, I would very much welcome a test for this recent regression.

[13:22:42] <jaraco> (or anything else that helps maintain contracts on which projects rely)

[13:22:52] <dhellmann> jaraco: I'm thinking "integration" style tests that actually install packages. Does that make sense?

[13:22:52] <dstufft> http://d.stufft.io/image/012V181p031E this is the only email I've gotten as far as Mail.app is concerned, but I've gotten in like 8 times (even though those 8 times were actually different messages with different contents, but the same message id)

[13:23:47] <Ivo> dhellmann: scripttest might help.. I've been wanting to do that with virtualenv as well

[13:25:13] <jaraco> dhellmann, that does make sense, if it can be done in a robust and reliable way.

[13:25:44] <dhellmann> jaraco: it would tie the tests to pypi availability, which might cause some issues on occasion

[13:26:15] <dhellmann> it wouldn't need to be super complex, though: given a list of dist names and python package names, create a virtualenv, install the dist, active the virtualenv, try to import the package

[13:26:25] <dhellmann> s/active/activate

[13:26:33] <dstufft> py.test paramterize :D

[13:26:35] <dhellmann> and that has to come first, of course

[13:27:04] <jaraco> you'll have to install virtualenv first, for that. Maybe consider a PEP-370 env instead.

[13:27:15] <jaraco> As setuptools doesn't depend on virtualenv.

[13:27:38] <dstufft> setuptools doesn't, but there's no reason why it's tests can't afaik

[13:27:39] <dhellmann> jaraco: is there a way to override where the user's site-packages dir is?

[13:28:00] <Ivo> but what just broke was py2 which doesn't have venv

[13:28:09] <dhellmann> I would hate to screw up (or just clutter up) a developer's local user dir

[13:28:27] <dstufft> Ivo: PEP 370 is --user

[13:28:32] <dstufft> not venv

[13:28:36] <Ivo> oh, mybad

[13:28:51] <dhellmann> ah, the environment variable PYTHONUSERBASE

[13:28:57] <dhellmann> nice, that's even better

[13:29:02] <dhellmann> the test can just set that to a tmp dir

[13:29:38] <Ivo> jaraco: you use windows?

[13:33:12] <DanielHolth> so what was it doing exactly?

[13:34:04] <jaraco> Ivo, I do.

[13:34:26] <jaraco> I try to use everything, though I generally gravitate toward Windows and Ubuntu

[13:34:50] <Ivo> jaraco: for ubuntu, recomend pyenv for testing with many pythons

[13:49:08] <pthiem> Ok, I out, later.

[14:38:14] <dhellmann> jaraco: When you have a few minutes, please let me know if https://github.com/jaraco/setuptools/pull/8 is heading in the right direction. The tests that are commented out fail, even though I can install those packages, so I think I'm missing some setup work.

[14:45:02] <Ivo> dhellmann: you could really just copy the .hgignore

[14:46:11] <dhellmann> Ivo: sure, I can do that

[14:47:09] <dhellmann> Ivo: updated

[14:48:12] <Ivo> hmm, i wonder if the setuptools.egg-info is in there eroneously

[14:48:28] <Ivo> jaraco before said that the folder was needed under vc

[14:49:16] <dhellmann> yeah, one file is in version control and is modified by the tests somehow

[14:49:22] <dhellmann> I left that alone, since I wasn't sure what was going on

[14:49:33] <dhellmann> I just realized the latest update isn't ignoring the pytest stuff

[14:49:39] <Ivo> nw, could probably be sorted out in a separate commit / pr

[14:50:23] <dhellmann> commit amended

[14:59:17] <Ivo> dhellmann: might try using the monkeypatch and tmpdir func args from pytest

[15:17:01] <dhellmann> Ivo: I'm not sure what those are. I copied some patterns from test_easy_install.py.

[15:17:49] <Ivo> http://pytest.org/latest/tmpdir.html http://pytest.org/latest/monkeypatch.html

[15:20:21] <dhellmann> Ivo: ok, I can look at that. I'm more worried about whether what I'm doing to set things up is correct, and about the fact that some of those tests fail for reasons I don't understand. I can update the fixture to use tmpdir and monkeypatch after we work that out.

[15:21:13] <Ivo> lolpypy

[15:21:44] <dhellmann> Ivo: I mean the tests I have commented out because they don't work for me locally. I guess I can uncomment them to show the failures in travis.

[15:21:50] <Ivo> dhellmann: same failure I got before, I think its related to another commit after 4.0 which needs to be fixed

Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Monday the 2nd of June, 2014