On Wed, Oct 10, 2012 at 6:15 PM, PJ Eby wrote:
> On Tue, Oct 9, 2012 at 7:53 PM, Daniel Holth 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 t
PJ Eby 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 sticking
On 10 October 2012 23:15, PJ Eby 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 might use" doesn't ap
On Tue, Oct 9, 2012 at 7:53 PM, Daniel Holth 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 have the (
On Tue, Oct 9, 2012 at 7:28 PM, Vinay Sajip 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
> leaving eggs out o
