Re: [Distutils] Entry points: specifying and caching

On Fri, Oct 27, 2017 at 5:34 AM, Nick Coghlan wrote: > On 27 October 2017 at 18:10, Nathaniel Smith wrote: >> >> On Thu, Oct 26, 2017 at 9:02 PM, Nick Coghlan wrote: >> > Option 2: temporary (or persistent) per-user-session cache >> > >> > * Pro: only the first query per path entry per user sess

Re: [Distutils] Entry points: specifying and caching

On 27 October 2017 at 18:10, Nathaniel Smith wrote: > On Thu, Oct 26, 2017 at 9:02 PM, Nick Coghlan wrote: > > Option 2: temporary (or persistent) per-user-session cache > > > > * Pro: only the first query per path entry per user session incurs a > linear > > DB read > > * Pro: given persistent

Re: [Distutils] Entry points: specifying and caching

On Thu, Oct 26, 2017 at 9:02 PM, Nick Coghlan wrote: > Option 2: temporary (or persistent) per-user-session cache > > * Pro: only the first query per path entry per user session incurs a linear > DB read > * Pro: given persistent cache dirs (e.g. XDG_CACHE_HOME, ~/.cache) even that > overhead can

Re: [Distutils] Entry points: specifying and caching

On 27 October 2017 at 01:45, Thomas Kluyver wrote: > > > On Thu, Oct 26, 2017, at 03:57 PM, Daniel Holth wrote: > > Would something as simple as a file per sys.path with the 'last modified > by installer' date be helpful? You could check those to determine whether > your cache was out of date. >

Re: [Distutils] Entry points: specifying and caching

On Thu, Oct 26, 2017, at 03:57 PM, Daniel Holth wrote: > Would something as simple as a file per sys.path with the 'last > modified by installer' date be helpful? You could check those to > determine whether your cache was out of date. I wonder if we could use the directory mtime for this? It's o

Re: [Distutils] Entry points: specifying and caching

I agree. The "malware" problem is really a "how do I understand which hooks run in each environment" problem. The hooks could slow down or confuse, frustrate people in ways that were unrelated to any malicious intent. The caching could just be a more efficient, lossless representation of the *.dis

Re: [Distutils] Entry points: specifying and caching

On 26 October 2017 at 18:33, Thomas Kluyver wrote: > Nathaniel raises the point that it may be easier to convince other package > managers to regenerate an entry points cache than to call arbitrary Python > hooks on install. > At least for RPM, we have file triggers now, whereby system packages

Re: [Distutils] Entry points: specifying and caching

On Sat, Oct 21, 2017, at 07:59 AM, Nick Coghlan wrote: > Yeah, here's the gist of what I had in mind regarding the malware > problem (i.e. aiming to ensure we don't get all of setup.py's problems > back again):> > - a package's own install hooks do *not* get called for that package > - hooks only

Re: [Distutils] Entry points: specifying and caching

On Fri, Oct 20, 2017 at 11:59 PM, Nick Coghlan wrote: > Yeah, here's the gist of what I had in mind regarding the malware problem > (i.e. aiming to ensure we don't get all of setup.py's problems back again): > > - a package's own install hooks do *not* get called for that package Doesn't that bre

Re: [Distutils] Entry points: specifying and caching

On 21 October 2017 at 18:21, Nick Coghlan wrote: > On 21 October 2017 at 18:04, Wes Turner wrote: > > On Saturday, October 21, 2017, Nick Coghlan wrote: > >> I'm also going to file an issue on the setuptools issue tracker to make > sure Jason is aware of what we're doing, and get his explicit O

Re: [Distutils] Entry points: specifying and caching

On 21 October 2017 at 18:04, Wes Turner wrote: > On Saturday, October 21, 2017, Nick Coghlan wrote: >> I'm also going to file an issue on the setuptools issue tracker to make sure Jason is aware of what we're doing, and get his explicit OK with the idea of making the format a PyPA interoperabilit

Re: [Distutils] Entry points: specifying and caching

On Saturday, October 21, 2017, Nick Coghlan wrote: > On 20 October 2017 at 23:42, Donald Stufft > wrote: > >> On Oct 20, 2017, at 9:35 AM, Nick Coghlan > > wrote: >> The interoperability spec is going to state that conflict resolution when >> the same name within a group is declared by multiple

Re: [Distutils] Entry points: specifying and caching

On 21 October 2017 at 05:26, Doug Hellmann wrote: > I would also like to compare the performance of a few approaches > (1 file per sys.path hash using INI, JSON, and sqlite; one file per > entry on sys.path using the same formats) using a significant number > of plugins (~100?) before we decide.

Re: [Distutils] Entry points: specifying and caching

On 20 October 2017 at 23:42, Donald Stufft wrote: > On Oct 20, 2017, at 9:35 AM, Nick Coghlan wrote: > The interoperability spec is going to state that conflict resolution when > the same name within a group is declared by multiple packages is the > responsibility of the group consumer, so docum

Re: [Distutils] Entry points: specifying and caching

On 21 October 2017 at 06:50, Daniel Holth wrote: > I like the idea of lifecycle hooks but I worry about the malware problem; > would there need to be a blacklist / whitelist / disable system? > (ignore-scripts=true is now a recommended part of anyone's npm > configuration) That is why we have avo

Re: [Distutils] Entry points: specifying and caching

I like the idea of lifecycle hooks but I worry about the malware problem; would there need to be a blacklist / whitelist / disable system? (ignore-scripts=true is now a recommended part of anyone's npm configuration) That is why we have avoided any kind of (package specific) hooks to wheel. However

Re: [Distutils] Entry points: specifying and caching

Excerpts from Nathaniel Smith's message of 2017-10-20 13:41:03 -0700: > On Oct 19, 2017 11:10, "Donald Stufft" wrote: > > > EXCEPT, for the fact that with the desire to cache things, it would be > beneficial to “hook” into the lifecycle of a package install. However I > know that there are other

Re: [Distutils] Entry points: specifying and caching

On Oct 19, 2017 11:10, "Donald Stufft" wrote: EXCEPT, for the fact that with the desire to cache things, it would be beneficial to “hook” into the lifecycle of a package install. However I know that there are other plugin systems out there that would like to also be able to do that (Twisted Plug

Re: [Distutils] Entry points: specifying and caching

On Friday, October 20, 2017, Doug Hellmann wrote: > Excerpts from Wes Turner's message of 2017-10-20 10:41:02 -0400: > > On Friday, October 20, 2017, Donald Stufft > wrote: > > > > > > > > > > > On Oct 20, 2017, at 9:35 AM, Nick Coghlan > > > ');>> > wrote: > > > > > > On 20 October 2017 at 23

Re: [Distutils] Entry points: specifying and caching

Excerpts from Thomas Kluyver's message of 2017-10-20 19:37:45 +0100: > On Fri, Oct 20, 2017, at 07:24 PM, Doug Hellmann wrote: > > I have been trying to find time to do something like that within > > stevedore for a while to solve some client-side startup performance > > issues with the OpenStack c

Re: [Distutils] Entry points: specifying and caching

On Fri, Oct 20, 2017, at 07:31 PM, Marius Gedminas wrote: > Please do not forget about gui_scripts entry points! I haven't forgotten about them in the draft spec: https://github.com/pypa/python-packaging-user-guide/pull/390/files#diff-089b079de062f6fdb759bb719b79e6c8R121 __

Re: [Distutils] Entry points: specifying and caching

On Fri, Oct 20, 2017 at 08:10:06AM -0400, Donald Stufft wrote: > Packaging tools shouldn’t be expected to know anything about it other > than the console_scripts feature Please do not forget about gui_scripts entry points! Marius Gedminas -- What can I do with Python that I can't do with C#? Yo

Re: [Distutils] Entry points: specifying and caching

On Fri, Oct 20, 2017, at 07:24 PM, Doug Hellmann wrote: > I have been trying to find time to do something like that within > stevedore for a while to solve some client-side startup performance > issues with the OpenStack client. I would be happy to help add it > to entrypoints instead and use it fr

Re: [Distutils] Entry points: specifying and caching

Excerpts from Nick Coghlan's message of 2017-10-20 14:42:09 +1000: > 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

Re: [Distutils] Entry points: specifying and caching

Excerpts from Wes Turner's message of 2017-10-20 10:41:02 -0400: > On Friday, October 20, 2017, Donald Stufft wrote: > > > > > > > On Oct 20, 2017, at 9:35 AM, Nick Coghlan > > wrote: > > > > On 20 October 2017 at 23:19, Donald Stufft > > wrote: > > > >> One that I was helping someone debug jus

Re: [Distutils] Entry points: specifying and caching

On Wed, 18 Oct 2017 at 17:54 Nick Coghlan wrote: > On 19 October 2017 at 04:18, Alex Grönholm > wrote: > >> Daniel Holth kirjoitti 18.10.2017 klo 21:06: >> >> >> http://setuptools.readthedocs.io/en/latest/formats.html?highlight=entry_points.txt#entry-points-txt-entry-point-plugin-metadata >> >>

Re: [Distutils] Entry points: specifying and caching

On Friday, October 20, 2017, Donald Stufft wrote: > > > On Oct 20, 2017, at 9:35 AM, Nick Coghlan > wrote: > > On 20 October 2017 at 23:19, Donald Stufft > wrote: > >> One that I was helping someone debug just the other day is that they’re >> super non-debuggable and the behavior when you have

Re: [Distutils] Entry points: specifying and caching

> On Oct 20, 2017, at 9:35 AM, Nick Coghlan wrote: > > On 20 October 2017 at 23:19, Donald Stufft > wrote: > One that I was helping someone debug just the other day is that they’re super > non-debuggable and the behavior when you have two things providing the same >

Re: [Distutils] Entry points: specifying and caching

On 20 October 2017 at 23:19, Donald Stufft wrote: > One that I was helping someone debug just the other day is that they’re > super non-debuggable and the behavior when you have two things providing > the same entry point is basically (If I remember correctly, the > behavior is that the firs

Re: [Distutils] Entry points: specifying and caching

On Oct 20, 2017, at 8:41 AM, Thomas Kluyver wrote: > > On Fri, Oct 20, 2017, at 01:36 PM, Donald Stufft wrote: >> Entry points have a lot of problems and I know of multiple systems that have >> either moved away from them, had to hack around how bad they are, have >> refused to implement them b

Re: [Distutils] Entry points: specifying and caching

On Fri, Oct 20, 2017, at 01:58 PM, Wes Turner wrote: > What were the issues with setuptools entry points here (in 2014, when > you two were opposed to adding them to sendibly list ipython > extensions)? I'm impressed by your memory! The main issue then was that it implied that extension authors wou

Re: [Distutils] Entry points: specifying and caching

On Friday, October 20, 2017, Thomas Kluyver wrote: > On Fri, Oct 20, 2017, at 01:36 PM, Donald Stufft wrote: > > Entry points have a lot of problems and I know of multiple systems that > have either moved away from them, had to hack around how bad they are, have > refused to implement them becaus

Re: [Distutils] Entry points: specifying and caching

On Fri, Oct 20, 2017, at 01:36 PM, Donald Stufft wrote: > Entry points have a lot of problems and I know of multiple systems > that have either moved away from them, had to hack around how bad they > are, have refused to implement them because of previous pain felt by > them, are looking for ways t

Re: [Distutils] Entry points: specifying and caching

> On Oct 20, 2017, at 8:34 AM, Nick Coghlan wrote: > > You're acting like you believe you have veto power over this topic. You don't > - it's not a PyPI related concern, and it doesn't require any changes to pip > or warehouse. > > I'd certainly be *happier* if you were only -0 rather than -

Re: [Distutils] Entry points: specifying and caching

> On Oct 20, 2017, at 8:23 AM, Nick Coghlan wrote: > > On 20 October 2017 at 22:10, Donald Stufft > wrote: > If I could guess, I’d say it hasn’t changed in years because setuptools has > had bigger things to work on and not enough time to do it in. > > Then you'd be w

Re: [Distutils] Entry points: specifying and caching

On 20 October 2017 at 22:18, Donald Stufft wrote: > > The “existing installations” is horse shit, because existing > implementations won’t support *any* new feature of anything so it can > literally be used as a justification for doing nothing about anything > except standardizing what already ex

Re: [Distutils] Entry points: specifying and caching

On Fri, Oct 20, 2017, at 01:18 PM, Donald Stufft wrote: > I guess we shouldn’t have done PEP 517 or PEP 518 because, by your > logic here, since it won’t be supported by existing tooling, there > won’t be any incentive for people to use it ever. I see this as having a similar purpose to those PEPs:

Re: [Distutils] Entry points: specifying and caching

On 20 October 2017 at 22:10, Donald Stufft wrote: > If I could guess, I’d say it hasn’t changed in years because setuptools > has had bigger things to work on and not enough time to do it in. Then you'd be wrong - it hasn't changed in years because it's a sensible, simple solution to the proble

Re: [Distutils] Entry points: specifying and caching

> On Oct 20, 2017, at 8:06 AM, Nick Coghlan wrote: > > On 20 October 2017 at 21:15, Donald Stufft > wrote: > Tell you what, I’ll drop everything today and write up a PEP that adds > metadata for console scripts to the packaging metadata where it belongs, > > Donald,

Re: [Distutils] Entry points: specifying and caching

On 20 October 2017 at 21:57, Thomas Kluyver wrote: > On Fri, Oct 20, 2017, at 12:50 PM, Donald Stufft wrote: > > * We stifle innovation (hell just including it in setutools at all does > > this, but we can’t unopen that can of worms). > > I don't think that's true to any significant extent. Havin

Re: [Distutils] Entry points: specifying and caching

> On Oct 20, 2017, at 7:57 AM, Thomas Kluyver wrote: > > On Fri, Oct 20, 2017, at 12:50 PM, Donald Stufft wrote: >> * Since it is a packaging standard, then it is expected that all >> packaging tools will be updated to work with it. > > Where packaging tools need to know about it, they alread

Re: [Distutils] Entry points: specifying and caching

On 20 October 2017 at 21:15, Donald Stufft wrote: > Tell you what, I’ll drop everything today and write up a PEP that adds > metadata for console scripts to the packaging metadata where it belongs, > Donald, you're making the same mistake I did with PEP 426: interoperability specifications are u

Re: [Distutils] Entry points: specifying and caching

On Fri, Oct 20, 2017, at 12:50 PM, Donald Stufft wrote: > * Since it is a packaging standard, then it is expected that all > packaging tools will be updated to work with it. Where packaging tools need to know about it, they already have to. Where they don't, writing a standard doesn't imply that

Re: [Distutils] Entry points: specifying and caching

> On Oct 20, 2017, at 7:31 AM, Thomas Kluyver wrote: > > On Fri, Oct 20, 2017, at 12:15 PM, Donald Stufft wrote: >> Tell you what, I’ll drop everything today and write up a PEP... > > Donald, why are you so determined that this spec should not be created? Your > time is enormously valuable, so

Re: [Distutils] Entry points: specifying and caching

On Fri, Oct 20, 2017, at 12:15 PM, Donald Stufft wrote: > Tell you what, I’ll drop everything today and write up a PEP... Donald, why are you so determined that this spec should not be created? Your time is enormously valuable, so why would you drop everything to write a PEP which implies changes

Re: [Distutils] Entry points: specifying and caching

> On Oct 20, 2017, at 1:32 AM, Nick Coghlan wrote: > > 3. Unlike setup.cfg & pyproject.toml, actual humans never touch it - it's > written and read solely by software This is wrong BTW, humans can and do effectively write entry_points.txt, it’s a supported feature of setuptools to do: setupt

Re: [Distutils] Entry points: specifying and caching

> On Oct 20, 2017, at 7:02 AM, Nick Coghlan wrote: > > That's the one point where the "de facto standard" status of setuptools is > relevant to the question of whether the entry_points.txt format is a PyPA > interoperability standard: it is, because providing a functionally equivalent > cap

Re: [Distutils] Entry points: specifying and caching

On 20 October 2017 at 20:48, Donald Stufft wrote: > > On Oct 20, 2017, at 1:32 AM, Nick Coghlan wrote: > > If we want to enable pytest plugin authors to use other build systems like > flit, then those build systems need a defined interoperability format > that's compatible with what pytest is ex

Re: [Distutils] Entry points: specifying and caching

On 20 October 2017 at 16:43, Thomas Kluyver wrote: > I would also be happy to add a section to the document describing the > specific use of entry points for defining scripts to install. > Yeah, it would make sense to include that, as well as reserving the "console_scripts" name on PyPI so we ab

Re: [Distutils] Entry points: specifying and caching

> On Oct 20, 2017, at 1:32 AM, Nick Coghlan wrote: > > If we want to enable pytest plugin authors to use other build systems like > flit, then those build systems need a defined interoperability format that's > compatible with what pytest is expecting to see (i.e. entry point definitions > th

Re: [Distutils] Entry points: specifying and caching

I would also be happy to add a section to the document describing the specific use of entry points for defining scripts to install. ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Entry points: specifying and caching

On Fri, Oct 20, 2017, at 05:42 AM, Nick Coghlan wrote: > 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 t

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 to me. > > > It does register them at inst

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 section named “console_scripts” and def

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 (2), its just another fi

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 doesn't > care otherwise about them) seems pretty reasonable to me. > > > It does register them at

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 generic feature of “you

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 instal

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 section named “console_scrip

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 sec

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 > the console_scripts

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 >> of those too. Since se

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 cours

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 controversial. They are a de-facto >>> packaging

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 than one tool that can c

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 than one that can consu

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 i

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 huge threads, heated deb

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 invo

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 some > mechanism i

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 >> without (2), its just anothe

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 ne

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 .dist-info directory and

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: f.writ

Re: [Distutils] Entry points: specifying and caching

On 19 October 2017 at 12:16, Daniel Holth wrote: > We said "you won't have to install setuptools" but actually "you don't > have to use it" is good enough. If you had 2 pkg-resources implementations > running you might wind up scanning sys.path extra times... > True, but that's where Thomas's sug

Re: [Distutils] Entry points: specifying and caching

We said "you won't have to install setuptools" but actually "you don't have to use it" is good enough. If you had 2 pkg-resources implementations running you might wind up scanning sys.path extra times... On Wed, Oct 18, 2017, 20:53 Nick Coghlan wrote: > On 19 October 2017 at 04:18, Alex Grönhol

Re: [Distutils] Entry points: specifying and caching

On 19 October 2017 at 04:18, Alex Grönholm wrote: > Daniel Holth kirjoitti 18.10.2017 klo 21:06: > > http://setuptools.readthedocs.io/en/latest/formats.html? > highlight=entry_points.txt#entry-points-txt-entry-point-plugin-metadata > > http://setuptools.readthedocs.io/en/latest/pkg_resources. > h

Re: [Distutils] Entry points: specifying and caching

On Wed, Oct 18, 2017 at 2:57 PM Paul Moore wrote: > On 18 October 2017 at 19:42, Thomas Kluyver wrote: > > On Wed, Oct 18, 2017, at 05:59 PM, Paul Moore wrote: > >> > I've always used the setuptools documentation as a reference. Are you > >> > suggesting moving that information to a different lo

Re: [Distutils] Entry points: specifying and caching

On Wed, Oct 18, 2017 at 2:18 PM Alex Grönholm wrote: > Daniel Holth kirjoitti 18.10.2017 klo 21:06: > > > http://setuptools.readthedocs.io/en/latest/formats.html?highlight=entry_points.txt#entry-points-txt-entry-point-plugin-metadata > > > http://setuptools.readthedocs.io/en/latest/pkg_resources.

Re: [Distutils] Entry points: specifying and caching

On 18 October 2017 at 19:42, Thomas Kluyver wrote: > On Wed, Oct 18, 2017, at 05:59 PM, Paul Moore wrote: >> > I've always used the setuptools documentation as a reference. Are you >> > suggesting moving that information to a different location to >> > allow/encourage other tools to implement it a

Re: [Distutils] Entry points: specifying and caching

On Wed, Oct 18, 2017, at 05:59 PM, Paul Moore wrote: > > I've always used the setuptools documentation as a reference. Are you > > suggesting moving that information to a different location to > > allow/encourage other tools to implement it as a standard? > > I've never used entry points myself (o

Re: [Distutils] Entry points: specifying and caching

Daniel Holth kirjoitti 18.10.2017 klo 21:06: http://setuptools.readthedocs.io/en/latest/formats.html?highlight=entry_points.txt#entry-points-txt-entry-point-plugin-metadata http://setuptools.readthedocs.io/en/latest/pkg_resources.html?highlight=pkg_resources#creating-and-parsing It is not ver

Re: [Distutils] Entry points: specifying and caching

http://setuptools.readthedocs.io/en/latest/formats.html?highlight=entry_points.txt#entry-points-txt-entry-point-plugin-metadata http://setuptools.readthedocs.io/en/latest/pkg_resources.html?highlight=pkg_resources#creating-and-parsing It is not very complicated. It looks like the characters are m

Re: [Distutils] Entry points: specifying and caching

On 18 October 2017 at 17:48, Doug Hellmann wrote: > Excerpts from Thomas Kluyver's message of 2017-10-18 15:52:00 +0100: >> We're increasingly using entry points in Jupyter to help integrate >> third-party components. This brings up a couple of things that I'd like >> to do: >> >> 1. Specification

Re: [Distutils] Entry points: specifying and caching

Excerpts from Thomas Kluyver's message of 2017-10-18 15:52:00 +0100: > We're increasingly using entry points in Jupyter to help integrate > third-party components. This brings up a couple of things that I'd like > to do: > > 1. Specification > > As far as I know, there's no document describing th

[Distutils] Entry points: specifying and caching

We're increasingly using entry points in Jupyter to help integrate third-party components. This brings up a couple of things that I'd like to do: 1. Specification As far as I know, there's no document describing the details of entry points; it's a de-facto standard established by setuptools. It s