
<!DOCTYPE html>

<html>

<head>

<title></title>

</head>

<body><div>On Fri, Oct 20, 2017, at 05:42 AM, Nick Coghlan wrote:<br></div>

<blockquote type="cite"><div dir="ltr"><div><div defang_data-gmailquote="yes"><div>I'm wondering if rather than jumping straight to a PEP, it may make sense to instead initially pursue this idea as a *non-*standard, implementation dependent thing specific to the "entrypoints" project. There are a *lot* of challenges to be taken into account for a truly universal metadata caching design, and it would be easy to fall into the trap of coming up with a design so complex that nobody can realistically implement it.<br></div>

</div>

</div>

</div>

</blockquote><div><br></div>

<div>I'd be happy to tackle it like that. Donald's proposed hooks for package installation and uninstallation would provide all the necessary interoperation between different tools. As and when it's working, the cache format can be documented for other consumers to use.<br></div>

<div><br></div>

<div>> Right now, the only documented publishing API for 

that pub/sub channel is setuptools.setup(), and the only documented subscription

 API is pkg_resources. Documenting the file format explicitly changes 

that dynamic, such that any publisher that produces a compliant 

`entry_points.txt` file will be supported by pkg_resources, and any 

consumer that can read a compliant `entry_points.txt` file will be 

supported by setuptools.setup()<br></div>

<div><br></div>

<div>Yup, this is very much what I'd like :-)<br></div>

<div><br></div>

<div>Thanks,<br></div>

<div>Thomas<br></div>

</body>

</html>