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

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 > > issu

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

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

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

Re: [Distutils] Multiple pips to go along with my multiple Pythons

Excerpts from Skip Montanaro's message of 2015-05-07 09:58:35 -0500: Thanks for the responses. I eventually decided to just download and expand the tarball, then execute PY setup.py clean -a PY setup.py install for each of my PYs. I then deleted the pip, pip2 and pip3 items, leaving only

Re: [Distutils] entry points PEP

On Jul 19, 2013, at 6:22 PM, Monty Taylor monty.tay...@gmail.com wrote: Yeah. Not moving to zc.buildout for anything. I believe it will be a better option to just write by-hand scripts that get installed that just do: from nova.rootwrap import cmd return cmd.main(sys.argv) or

Re: [Distutils] time for packaging summit at pycon

OK, thanks! On Feb 27, 2013, at 10:54 PM, Nick Coghlan wrote: On Thu, Feb 28, 2013 at 12:32 AM, Doug Hellmann doug.hellm...@gmail.com wrote: The Packaging Summit page [1] lists Friday evening but doesn't specify a time or location, as far as I can tell. Have those been set, yet? Doug

[Distutils] time for packaging summit at pycon

The Packaging Summit page [1] lists Friday evening but doesn't specify a time or location, as far as I can tell. Have those been set, yet? Doug [1] https://us.pycon.org/2013/community/openspaces/packaginganddistributionminisummit/ ___ Distutils-SIG

[Distutils] need guidance on state-of-the-art for entry points

Dear Fellowship, I am starting a new project which will be heavily extensible using plugins defined in other people's packages over which I have little or no control. I was planning to use setuptools entry points to manage the plugin discovery, since it has worked so well for

Re: [Distutils] need guidance on state-of-the-art for entry points

OK, thanks! On Apr 25, 2012, at 1:39 PM, Ronny Pfannschmidt wrote: Hi doug, currently just distribute/setuptools is the way to go, later on packaging/ds2 will probably provide a replacement, but thats currently not usable/feature complete -- Ronny On 04/25/2012 07:33 PM, Doug

Re: [Distutils] problem with sdist for nested packages

On Sep 8, 2010, at 12:56 PM, P.J. Eby wrote: At 12:00 PM 9/8/2010 -0400, Doug Hellmann wrote: Instead of explicitly listing packages, I use find_package_data() and then get the package names from that result. The odd thing is I get a package PyMOTW.ElementTree

[Distutils] problem with sdist for nested packages

I'm having some problems creating an sdist for a nested package where some of the levels only include __init__.py and the subdirectories. The full list of files is fairly long, but here's a snippet to give you an idea of the layout for the inputs: PyMOTW/xml PyMOTW/xml/__init__.py

Re: [Distutils] problem with sdist for nested packages

Forgot to include version info: Python 2.7 distribute 0.6.10 Paver 1.0.3 Doug On Sep 8, 2010, at 7:34 AM, Doug Hellmann wrote: I'm having some problems creating an sdist for a nested package where some of the levels only include __init__.py and the subdirectories. The full list of files

Re: [Distutils] problem with sdist for nested packages

On Sep 8, 2010, at 7:37 AM, Eric Smith wrote: On 9/8/10 7:34 AM, Doug Hellmann wrote: I'm having some problems creating an sdist for a nested package where some of the levels only include __init__.py and the subdirectories. The full list of files is fairly long, but here's a snippet

Re: [Distutils] problem with sdist for nested packages

On Sep 8, 2010, at 12:56 PM, P.J. Eby wrote: At 12:00 PM 9/8/2010 -0400, Doug Hellmann wrote: Instead of explicitly listing packages, I use find_package_data() and then get the package names from that result. The odd thing is I get a package PyMOTW.ElementTree

[Distutils] Distribute bootstrap question

I just released my first new piece of software using Distribute, and I'm still confused about whether I have the packaging correct. I think not, because a user has reported receiving a SandboxViolation error when trying to install the package with easy_install (bug report at:

Re: [Distutils] Adding entry points into Distutils ?

On May 6, 2009, at 9:38 PM, Wheat wrote: I'll also mention my most common use-case for using entry_points is installing console_scripts using zc.recipe.egg. I'm curious about that because I've never understood the benefit of using entry points for console scripts. Why not just list the

Re: [Distutils] Adding entry points into Distutils ?

On May 7, 2009, at 8:54 AM, Paul Moore wrote: 2009/5/7 Doug Hellmann doug.hellm...@gmail.com: I would argue the other way. Why force authors of console scripts to deal with entry points instead of just installing the script as-is? Please explain as-is with reference to ensuring

Re: [Distutils] Adding entry points into Distutils ?

On May 7, 2009, at 10:03 AM, Paul Moore wrote: 2009/5/7 Doug Hellmann doug.hellm...@gmail.com: Does setuptools give me something extra for Windows? I'm not a regular Windows user, so it's likely that there are features I don't know about. I don't think so, as such. It gives Unix

Re: [Distutils] Adding entry points into Distutils ?

On May 7, 2009, at 10:20 AM, Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eric Smith wrote: Doug Hellmann wrote: On May 7, 2009, at 8:54 AM, Paul Moore wrote: 2009/5/7 Doug Hellmann doug.hellm...@gmail.com: I would argue the other way. Why force authors of console

Re: [Distutils] Adding entry points into Distutils ?

On May 7, 2009, at 5:53 PM, Ben Finney wrote: Doug Hellmann doug.hellm...@gmail.com writes: I write a python script call hello.py like this: #!/usr/bin/env python def main(): print 'hello!' if __name__ == '__main__': main() Why make

Re: [Distutils] Adding entry points into Distutils ?

On May 7, 2009, at 7:28 PM, P.J. Eby wrote: At 10:38 AM 5/7/2009 -0400, Doug Hellmann wrote: pip installs my scripts into a virtualenv without any issue and without using entry points, AFAICT. I guess if we move to requiring entry points and disallowing simple script distribution I'll need

Re: [Distutils] Adding entry points into Distutils ?

On May 5, 2009, at 10:50 PM, P.J. Eby wrote: At 12:03 PM 5/6/2009 +1000, Ben Finney wrote: I don't see any advantage, in the context of this discussion, to having an additional, incompatible naming for full-path-to-a-class. Setuptools doesn't limit an entry point to being a class,

Re: [Distutils] Adding entry points into Distutils ?

On May 5, 2009, at 4:49 AM, Tarek Ziadé wrote: On Tue, May 5, 2009 at 1:57 AM, Ian Bicking i...@colorstudy.com wrote: Not strong, but I have a few issues with how they are currently defined: * There's the issue of activated and unactivated eggs, of course, but I guess that will be moot

Re: [Distutils] Adding entry points into Distutils ?

On May 5, 2009, at 8:15 AM, Tarek Ziadé wrote: On Tue, May 5, 2009 at 1:57 PM, Doug Hellmann doug.hellm...@gmail.com wrote: If I have to turn on the plugin, then what benefit does an entry point registry give me? I don't understand this sentence, since you say later that you want

Re: [Distutils] Adding entry points into Distutils ?

On May 5, 2009, at 9:33 AM, Tarek Ziadé wrote: On Tue, May 5, 2009 at 2:41 PM, Doug Hellmann doug.hellm...@gmail.com wrote: I am confused with the role of this man in the middle. In my mind there are plugins on one side, and host applications that consumes them if they wish on they other

Re: [Distutils] Adding entry points into Distutils ?

On May 5, 2009, at 10:38 AM, P.J. Eby wrote: At 08:41 AM 5/5/2009 -0400, Doug Hellmann wrote: I don't want new functionality available to an application just because someone has permission to install a package somewhere in the PYTHONPATH. I would rather have plugins added to an app through

Re: [Distutils] Adding entry points into Distutils ?

On May 5, 2009, at 11:05 AM, Tarek Ziadé wrote: On Tue, May 5, 2009 at 4:29 PM, Doug Hellmann doug.hellm...@gmail.com wrote a configuration file that reunites all entry points an application uses. For the Atomisator example: [atomisator.reader] rss = somepackage.somemodule:MyPluginClass