Re: [Distutils] Entry points: specifying and caching

def get_env_json_path(): directory = $VIRTUAL_ENV || ? return os.path.join(directory, ENV_JSON_FILENAME) def on_install(pkg_json): env_json_path = get_env_json_path() env_json = json.load(env_json_path) env_json['pkgs’][pkgname] = pkg_json with open(env_json_path, 'w') as f:

Re: [Distutils] Entry points: specifying and caching

On Thu, Oct 19, 2017, at 08:01 PM, Donald Stufft wrote: > >> On Oct 19, 2017, at 2:54 PM, Thomas Kluyver >> wrote:>> >> I don't think this needs to be controversial. They are a de-facto >> packaging standard, whether or not that's theoretically necessary. >> There's more

Re: [Distutils] Entry points: specifying and caching

> On Oct 19, 2017, at 3:15 PM, Thomas Kluyver wrote: > > On Thu, Oct 19, 2017, at 08:01 PM, Donald Stufft wrote: >> >>> On Oct 19, 2017, at 2:54 PM, Thomas Kluyver >> > wrote: >>> >>> I don't think this needs to be

Re: [Distutils] Entry points: specifying and caching

On Thu, Oct 19, 2017, at 08:29 PM, Donald Stufft wrote: > Because it is? A generic plugin mechanism is not a packaging feature > any more then a HTTP client is a packaging feature, but setuptools > contains one of those too. Since setuptools was in large part a > packaging library, it will of

Re: [Distutils] Entry points: specifying and caching

> On Oct 19, 2017, at 12:14 PM, Thomas Kluyver wrote: > > On Thu, Oct 19, 2017, at 04:10 PM, Donald Stufft wrote: >> I’m in favor, although one question I guess is whether it should be a a >> PEP or an ad hoc spec. Given (2) it should *probably* be a a PEP (since >>

Re: [Distutils] Entry points: specifying and caching

> On Oct 19, 2017, at 4:04 PM, Donald Stufft wrote: > > Like I said, I’m perfectly fine documenting that if you add an > entry_points.txt to the .dist-info directory, that is an INI file that > contains a section named “console_scripts” and define what is valid inside of >

Re: [Distutils] Entry points: specifying and caching

> On Oct 19, 2017, at 4:36 PM, Thomas Kluyver wrote: > > On Thu, Oct 19, 2017, at 09:04 PM, Donald Stufft wrote: >> Like I said, I’m perfectly fine documenting that if you add an >> entry_points.txt to the .dist-info directory, that is an INI file that >> contains a

Re: [Distutils] Entry points: specifying and caching

On 10/19/2017 04:57 PM, Donald Stufft wrote: > Because the feature is unrelated to packaging other than the fact we > currently utilize it for console_scripts. That seems like an odd perspective. Console scripts may be the only bit of entry points which is used *by the packaging system* at

Re: [Distutils] Entry points: specifying and caching

On 19 October 2017 at 19:09, Donald Stufft wrote: > > So heres a different idea that is a bit more ambitious but that I think is a > better overall idea. Let entrypoints be a setuptools thing, and lets define > some key lifecycle hooks during the installation of a package and

Re: [Distutils] Entry points: specifying and caching

> On Oct 19, 2017, at 2:28 PM, Paul Moore wrote: > > While I agree with this, one thing I have noticed with recent work is > that standardising existing things has typically been relatively > painless and stress-free. But designing new mechanisms generally ends > up with

Re: [Distutils] Entry points: specifying and caching

> On Oct 19, 2017, at 3:55 PM, Thomas Kluyver wrote: > > On Thu, Oct 19, 2017, at 08:29 PM, Donald Stufft wrote: >> Because it is? A generic plugin mechanism is not a packaging feature any >> more then a HTTP client is a packaging feature, but setuptools contains one >>

Re: [Distutils] Entry points: specifying and caching

On Thu, Oct 19, 2017, at 09:04 PM, Donald Stufft wrote: > Like I said, I’m perfectly fine documenting that if you add an > entry_points.txt to the .dist-info directory, that is an INI file that > contains a section named “console_scripts” and define what is valid > inside of the console_scripts

Re: [Distutils] Entry points: specifying and caching

> On Oct 19, 2017, at 5:26 PM, Tres Seaver wrote: > > Having the packaging > system register those services at installation time (even if it doesn't > care otherwise about them) seems pretty reasonable to me. It does register them at installation time, using an entirely

Re: [Distutils] Entry points: specifying and caching

On Thu, Oct 19, 2017, at 07:09 PM, Donald Stufft wrote: > So heres a different idea that is a bit more ambitious but that I think > is a better overall idea. Let entrypoints be a setuptools thing, and lets > define some key lifecycle hooks during the installation of a package and > some mechanism

Re: [Distutils] Entry points: specifying and caching

I prefer a single more generic mechanism that packaging happens to use instead of making special mechanisms for scripts or other callables that packaging might some day be interested in. One API, I can type pkg_resources.iter_entry_points('console_scripts') to enumerate the scripts and perhaps

Re: [Distutils] Entry points: specifying and caching

> On Oct 19, 2017, at 2:54 PM, Thomas Kluyver wrote: > > I don't think this needs to be controversial. They are a de-facto > packaging standard, whether or not that's theoretically necessary. > There's more than one tool that can create them (setuptools, flit), and > more

Re: [Distutils] Entry points: specifying and caching

On 20 October 2017 at 06:34, Donald Stufft wrote: > > On Oct 19, 2017, at 4:04 PM, Donald Stufft wrote: > > Like I said, I’m perfectly fine documenting that if you add an > entry_points.txt to the .dist-info directory, that is an INI file that > contains a

Re: [Distutils] Entry points: specifying and caching

> On Oct 18, 2017, at 10:52 AM, Thomas Kluyver wrote: > > > 1. Specification > I’m in favor, although one question I guess is whether it should be a a PEP or an ad hoc spec. Given (2) it should *probably* be a a PEP (since without (2), its just another file in the

Re: [Distutils] Entry points: specifying and caching

On 20 October 2017 at 02:14, Thomas Kluyver wrote: > On Thu, Oct 19, 2017, at 04:10 PM, Donald Stufft wrote: > > I’m in favor, although one question I guess is whether it should be a a > > PEP or an ad hoc spec. Given (2) it should *probably* be a a PEP (since > > without

Re: [Distutils] Entry points: specifying and caching

On Thu, Oct 19, 2017, at 04:10 PM, Donald Stufft wrote: > I’m in favor, although one question I guess is whether it should be a a > PEP or an ad hoc spec. Given (2) it should *probably* be a a PEP (since > without (2), its just another file in the .dist-info directory and that > doesn’t actually

Re: [Distutils] Entry points: specifying and caching

On Thursday, October 19, 2017, Donald Stufft wrote: > > On Oct 19, 2017, at 5:26 PM, Tres Seaver > wrote: > > Having the packaging > system register those services at installation time (even if it

Re: [Distutils] Entry points: specifying and caching

On 20 October 2017 at 07:33, Donald Stufft wrote: > > On Oct 19, 2017, at 5:26 PM, Tres Seaver wrote: > > Having the packaging > system register those services at installation time (even if it doesn't > care otherwise about them) seems pretty reasonable