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
On Mon, Oct 8, 2012 at 5:14 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
What do *you* mean by entry point? My understanding is that it represents the
start of some executable code. Wikipedia:
In computer programming, an entry point is a memory address, corresponding
to a
point in the
PJ Eby pje at telecommunity.com writes:
In pkg_resources, entry points are references to any importable
object. They don't have to be callables.
Note, however, that if you load an entry point which is a module, then
of course the module code will be executed as a side-effect, so
On Tue, Oct 9, 2012 at 5:45 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Clearly, distlib can't do things exactly
the way they're done in pkg_resources and setuptools, since those are not
considered suitable to go into the stdlib,
The two aren't 100% connected, even assuming the antecedent
PJ Eby pje at telecommunity.com writes:
More to the point, though, if it's not possible for someone to create
a wrapper to reimplement these portions of the pkg_resources API, then
it's going to be harder to get people to port their code.
I will give some thought to migration concerns. I'm
On Tue, Oct 9, 2012 at 5:45 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
PJ Eby pje at telecommunity.com writes:
In pkg_resources, entry points are references to any importable
object. They don't have to be callables.
Note, however, that if you load an entry point which is a module, then
On Mon, Oct 8, 2012 at 2:05 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
I've now updated distlib to include equivalent functionality for
pkg_resources'
entry points. There is no ability to install packages on-demand via
require()
functionality, but distributions are able to register
On Mon, Oct 8, 2012 at 9:34 PM, Vinay Sajip vinay_sa...@yahoo.co.uk wrote:
Registry of what ever you like - pointers to data, perhaps. Any use of the
registry, just like entry points, is a matter of convention between consenting
/ cooperating developers and their applications/libraries, or am I
Lennart Regebro regebro at gmail.com writes:
IIUC, you're allowed to just define a module or package without the
attributes appearing after the :
Right, but isn't that then an entry point?
How is it an entry point? Perhaps I'm misunderstanding what an entry point is,
but to my mind it's
Daniel Holth dholth at gmail.com writes:
I would prefer to keep the filename the same as long as the format is
the same.
See my comments about read_registry and write_registry methods in Distribution
(in response to Lennart's post).
In other words, it is a hassle and the feature is the same.
14 matches
Mail list logo
