On Tue, Oct 9, 2012 at 7:28 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
I don't believe that wheels are meant to be directly importable, but I could
be wrong about that. I am not sure why callee dependencies need to be
transparently met by distributions not on sys.path; Broadly speaking, and
On Tue, Oct 9, 2012 at 7:53 PM, Daniel Holth dho...@gmail.com wrote:
would also like to be able to store my installed package database in
sqlite3 by implementing an appropriate distlib/pkg_resources backend
and defining a standard post-(un)install index this new package hook
but I doubt I will
On 10 October 2012 23:15, PJ Eby p...@telecommunity.com wrote:
However, for the application platform plugins use case, wheels can
potentially be quite awesome, because you can build one fat wheel for
all your supported platforms. We don't want to inlcude .pyc files
for all the Pythons you
PJ Eby pje at telecommunity.com writes:
I'm not saying distlib must support all these plugin usecases
*itself*, but if it solves its chosen usecases in a way that can't be
*adapted by others* to handle the app platform use cases, then there's
not going to be an appealing alternative to
On Wed, Oct 10, 2012 at 6:15 PM, PJ Eby p...@telecommunity.com wrote:
On Tue, Oct 9, 2012 at 7:53 PM, Daniel Holth dho...@gmail.com wrote:
would also like to be able to store my installed package database in
sqlite3 by implementing an appropriate distlib/pkg_resources backend
and defining a
