PMXBOT Log file Viewer

Help | Karma | Search:

#pypa-dev logs for Wednesday the 16th of December, 2015

(Back to #pypa-dev overview) (Back to channel listing) (Animate logs)
[00:54:18] <pmxbot> jaraco pushed 3 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :
[00:54:19] <pmxbot> Bumped to 19.0 in preparation for next release.
[00:54:19] <pmxbot> Added tag 19.0 for changeset cc41477ecf92
[00:54:19] <pmxbot> Bumped to 19.1 in preparation for next release.
[02:58:09] <pmxbot> jaraco pushed 7 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :
[02:58:09] <pmxbot> ez_setup now loads latest version using metadata
[02:58:09] <pmxbot> Just use the indicated version directly.
[02:58:09] <pmxbot> Use contextlib.closing for the response
[02:58:10] <pmxbot> Restore Python 2.7 compatibility
[02:58:10] <pmxbot> release script no longer mutates ez_setup.py
[02:58:10] <pmxbot> No longer need to specify a version in the test run.
[02:58:10] <pmxbot> Update changelog
[13:06:29] <pmxbot> jaraco pushed 1 commit to setuptools (https://bitbucket.org/pypa/setuptools/) :
[13:06:30] <pmxbot> Fixes #475: correct a typo in metadata environment marker evaluation
[13:22:27] <pmxbot> jaraco pushed 3 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :
[13:22:27] <pmxbot> Update changelog
[13:22:27] <pmxbot> Now that bootstrap script automatically installs the latest published version, it's no longer necessary to track the _current_ bootstrap version with a bookmark.
[13:22:27] <pmxbot> Update changelog to reference ticket
[13:24:45] <pmxbot> jaraco pushed 2 commits to setuptools (https://bitbucket.org/pypa/setuptools/) :
[13:24:45] <pmxbot> Added tag 19.1 for changeset 834782ce4915
[13:24:45] <pmxbot> Bumped to 19.2 in preparation for next release.
[13:30:37] <pmxbot> jaraco pushed 1 commit to setuptools (https://bitbucket.org/pypa/setuptools/) :
[13:30:37] <pmxbot> Experiment with using setuptools_scm for release management. This approach drastically simplifies the codebase, but imposes an initial dependency at install time, which could prove problemmatic in scenarios where connectivity is limited. This approach may not be viable for real-world consumption, but I'm committing it in this branch for consideration with no plans to release it without more testing and discussion.
[13:46:16] <ronny> jaraco: sup, how about having a sdist variant that will pip install -- target without byte compiling and having setup?requires look there
[13:46:51] <ronny> jaraco: then sdists coud be fat and include the setup_requires as wheels installed in a setup site
[13:47:33] <ronny> (and this could later be used to delegate all work to pip once the build tool pep lands
[13:52:16] <jaraco> I have a similar idea in mind - where there’s a function of a build tool (or an even more general tool serving the needs of things like pytest-runner as well) that will temporarily inject dependencies for the running process. It could keep these dependencies in a runnable form (like eggs or installed wheels) in a cache, similar to pip’s package cache, except runnable, but would be selectable on demand, rather than permanently instal
[13:53:21] <jaraco> I’m less excited about the idea of vendorizing setup_requires, because that violates the principle of re-use.
[13:55:33] <jaraco> I haven’t fully fleshed out the ideas. I need to write up more on it another time.
[17:41:55] <pypabot> Deployed dc2d370 to Warehouse (Production)
[18:36:34] <pypabot> Deployed b590404 to Warehouse (Production)
[22:44:49] <xafer> hello dstufft, how is the move going ?
[23:08:44] <sigmavirus24> xafer: it's probably moving along
[23:12:33] <xafer> :-o
[23:15:09] <dstufft> xafer: we're all moved in :D still living out of boxes for a lot of things, but we're here now
[23:20:16] <xafer> great news :)