Log file Viewer
#pypa-dev logs for Saturday the 14th of June, 2014
[13:05:48] <pmxbot> jaraco pushed 3 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :
[13:18:53] <Alex_Gaynor> jaraco: is there going to be a 4.0 release? I believe it was effected as well
[14:13:15] <pmxbot> jaraco pushed 3 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :
[14:13:15] <pmxbot> Closing this head, as it conflates #202 with #218 and #210. Refer to dfdc08c6a616 for issue202.
[14:28:33] <pmxbot> jaraco pushed 5 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :
[14:36:29] <pmxbot> jaraco pushed 2 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :
[14:44:32] <pmxbot> Now that 2to3 is no longer run on the codebase, it's safe for the templates to be syntactically incorrect (prior to substitution).
[14:57:41] <pmxbot> jaraco pushed 4 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :
[15:11:32] <jaraco> Ivo, and that's fine. My focus today was to make sure we had separate branches (Mercurial bookmarks) of the various heads with a stable master so that development can continue in master while the individual issues are addressed in respective branches.
[15:12:44] <jaraco> Yes, 218 was "fixed" by removing the offending commits and releases in the 4.0 line.
[15:36:36] <jaraco> Well, since 3.8.1 supersedes it, they should be able to use that version next. I hope that's not a problem.
[15:37:00] <Ivo> https://projects.archlinux.org/svntogit/packages.git/log/trunk?h=packages/python-setuptools
[15:39:07] <jaraco> Because 3.8.1 doesn't include the changes introduced in 4.0. It is as advertised, a rollback.
[15:41:20] <jaraco> But the one proposed fix strikes me as adding complication without any way to manage it.
[15:41:44] <jaraco> Namely https://bitbucket.org/pypa/setuptools/pull-request/60/fix-regression-in-issue-218/diff
[15:42:57] <jaraco> So I'm suggesting that we step back and understand the problem better, establish some tests, and better formalize the interface.
[15:43:28] <Ivo> that way you might fix these issues, and also a number coming from divergent behaviour between the two codebases
[15:44:12] <jaraco> If you look at #210, you'll see that the crux of this change was that the user expects to be able to install arbitrary binaries (as scripts).
[15:44:23] <Ivo> well vendoring is just the mechanism you use to statically include shared code between two projects, right
[15:44:37] <jaraco> A requirement which is highly implicit and contradicts the use case described in the Python docs.
[15:45:02] <jaraco> I'm slightly tempted to say that use case should not be supported... and possibly consider adding a separate option for that need.
[15:45:52] <Ivo> jaraco: consider writing deprecation notices, or asking about issuing them on the ML if they're anything big...
[15:46:54] <jaraco> I had not expected this change to have substantial impact except maybe to make 'setup.py develop' installed scripts appear with non-normative newlines.
[15:46:59] <Ivo> would it be possible to revert script creation behaviour to distutils when using scripts=[]
[15:48:15] <jaraco> hmm. maybe. but probably not. I'm sure there are lots of use cases depending on the existing behavior, including rewriting the headers.
[15:48:25] <Ivo> alternatively, just say "yeah distutils is f***ing crazy; this isn't gonna work when used with setuptools anymore'
[15:51:18] <Ivo> tomprince: the trouble we're having is with supporting existing stuff correctly; adding stuff might be useful, but doesn't solve the existing problem
[15:52:34] <jaraco> if it's the right thing to do, though, we should introduce that feature now so it can start percolating.
[15:52:47] <tomprince> Well, one of the suggetions is saying "we don't support that". It would be more palatable if you could continue "but use this instead which we do support"
[15:53:00] <jaraco> That's why in #210, I've asked for a more concrete example to capture the use case and start to establish requirements.
[16:31:35] <pmxbot> jaraco pushed 13 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :
[16:31:35] <pmxbot> Implement 'build_manifest' as a classmethod. Rename to 'build' because Manifests is already in the classname.
[16:49:34] <dstufft> jaraco: can you just release a 4.1 or something that has the same contents as 3.8.1? I know it techincally breaks semver but deleting versions like that is going to confuse any mirrors which don't delete files
[16:57:15] <pmxbot> jaraco pushed 3 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :
[17:29:29] <Ivo> ionelmc: yes; 4.0 had bad functionality that can't be bugfixed atm, so we preferred to push out a new major version to remove it again
[17:30:17] <Ivo> because to remove functionality is to break api which according to semver needs a new major version
[17:31:21] <ionelmc> Ivo: but https://bitbucket.org/pypa/setuptools/issue/210 only changes behavior, no new api
[17:32:31] <ionelmc> Ivo: http://webcache.googleusercontent.com/search?q=cache:https://bitbucket.org/pypa/setuptools/issue/210&ie=utf-8&oe=utf-8&rls=org.mozilla:en-US:official&client=firefox-a&channel=sb&gws_rd=cr&ei=04acU9K0FurA7AaD-IDwDg
[17:45:56] <mordred> File "/tmp/user/0/pip_build_root/setuptools/setuptools/script template.py", line 2
[17:50:17] <mordred> dstufft: you forgot - you really want the stderr stuff even if you didn't know it
[17:50:19] <dstufft> I just looked how I can disable that error so it just silently doesn't compile stuff
[17:51:56] <dstufft> I guess I can rewrite compileall.compile_dir using py_compile with do_raise=True
[18:05:28] <mordred> dstufft: with the templates referred to above, does that mean there is a newer/better way to override the script tmpl? or is it just code org?
[18:34:34] <jaraco> I can back out the change that created those syntax errors. Shouldn't need to patch in pip.
[18:47:32] <dstufft> jaraco: well it's up to you. the problem needs fixed in pip regardless since setuptools isn't the only place that the problem exists in
[18:48:25] <jaraco> it appears when installing setuptools itself. It's probably worth fixing. Thanks for understanding though.
[20:15:46] <pmxbot> jaraco pushed 3 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :
[20:20:16] <agronholm> so I've been told, but was setuptools so badly broken that a new major version is required every 2 months?
[21:58:58] <dstufft> merge conflicts are a problem, and no good way to really enforce that a changelog entry was added
[21:59:38] <Ivo> we could just decide to be more strict on not accepting PRs without changelog entries
[22:01:12] <dstufft> also people generally feel less angsty if a machine tells them their thing is wrong than if a human does
[22:01:14] <Ivo> add something in the travis build to check that a PR contains a modification to changes.rst? :S
[22:01:40] <dstufft> so the problem with that, is not every change really deserves an entry in the change log
[22:02:25] <dstufft> if your change doesn't deserve to be called out specially in the changelog, you add a foo.misc file instead of a foo.bugfix or whatever
[22:02:48] <dstufft> and when the changelog is created, all of the .misc stuff is just lumped together in a list of issues that were fixed but with no prose associated with them
[22:03:25] <dstufft> so you enforce that a foo.<something> was added, and the <something> tells the changelog generation how to interpret it
[22:03:40] <dstufft> bitprophet's thing could do that, if it added a :misc: category that did the same thing
[22:04:17] <dstufft> Ivo: it's what Twisted calls it, basically instead of editing a single CHANGES.rst file, you have a directory, and each change log entry gets it's own file
[22:05:02] <dstufft> then the release process takes all of those files, and generates a change log from it
[22:08:38] <Ivo> hmm, well https://virtualenv.pypa.io/en/develop/ is different from https://virtualenv.pypa.io/en/latest/
[22:11:56] <dstufft> ok, wasn't sure since you asked about what topfiles were, maybe I didn' mention that Twisted calls their news thing topfiles