Paul Moore wrote:
2009/5/9 Chris Withers ch...@simplistix.co.uk:
+1.
flameAnyone who's arguing against this is either not deploying stuff in a
repeatable fashion, and so isn't serious in my books, or is so serious that
they're cutting vm images to roll out and so dump everything for the app in
Eric Smith wrote:
Paul Moore wrote:
2009/5/7 Tres Seaver tsea...@palladion.com:
Eric Smith wrote:
Yes. It creates a .exe wrapper [1]. By using entry points, I don't need
to care what the target system is. Also, /usr/bin/env might invoke the
wrong python.
Exactly: using entry points for
Noah Gift wrote:
I don't understand what you mean here, either.
In film enviroments the whole way we work is by toggling between
different enviroments. A developer, artists, etc, will need to work
on a specific shot in a movie, and they also need to toggle between
films, etc.
Have you guys
Noah Gift wrote:
3. There doesn't seem to be a clean way to inject user specific
environment details to the console script.
os.environ?
Either than, or I'm not following you...
Chris
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
2009/5/9 Chris Withers ch...@simplistix.co.uk:
+1.
flameAnyone who's arguing against this is either not deploying stuff in a
repeatable fashion, and so isn't serious in my books, or is so serious that
they're cutting vm images to roll out and so dump everything for the app in
site
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Chris Withers wrote:
Noah Gift wrote:
I don't understand what you mean here, either.
In film enviroments the whole way we work is by toggling between
different enviroments. A developer, artists, etc, will need to work
on a specific shot in a
There are *many* benefits of adding entry points into Distutils. In
fact, adding a plugin system in there,
will help make the commands more extendable and therefore will help us
in the long term to remove things
out of Distutils.
So any strong opinion against them ?
If not, I'll add
On Thu, May 7, 2009 at 7:18 AM, P.J. Eby p...@telecommunity.com wrote:
At 08:28 PM 5/6/2009 +0200, Hanno Schlichting wrote:
Doug Hellmann wrote:
On May 6, 2009, at 1:46 PM, P.J. Eby wrote:
At 10:59 AM 5/6/2009 -0400, Doug Hellmann wrote:
On May 5, 2009, at 10:50 PM, P.J. Eby wrote:
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
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 that the script
works cross-platform. I think the benefit of
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 that the
2009/5/7 Doug Hellmann doug.hellm...@gmail.com:
I write a python script call hello.py like this:
#!/usr/bin/env python
def main():
print 'hello!'
if __name__ == '__main__':
main()
Why make me define an entry point for that? I can just
On Thu, May 07, 2009 at 03:03:29PM +0100, Paul Moore wrote:
2009/5/7 Doug Hellmann doug.hellm...@gmail.com:
Why make me define an entry point for that? I can just put it in /usr/bin
or somewhere in the path on Windows and call it as hello.py.
That works but a lot of Unix users have in the
-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 scripts to
deal
with entry points instead of just
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 and
2009/5/7 Tres Seaver tsea...@palladion.com:
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 scripts to
deal
with entry points instead of just
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
I write a python script call hello.py like this:
#!/usr/bin/env python
def main():
print 'hello!'
if __name__ == '__main__':
main()
Why make me define an entry point for that? I can just put it in /usr/
bin or somewhere in the
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 me define an entry point for that? I can just
Paul Moore wrote:
2009/5/7 Tres Seaver tsea...@palladion.com:
Eric Smith wrote:
Yes. It creates a .exe wrapper [1]. By using entry points, I don't need
to care what the target system is. Also, /usr/bin/env might invoke the
wrong python.
Exactly: using entry points for console scripts
On Fri, May 8, 2009 at 10:04 AM, Eric Smith e...@trueblade.com wrote:
Paul Moore wrote:
2009/5/7 Tres Seaver tsea...@palladion.com:
Eric Smith wrote:
Yes. It creates a .exe wrapper [1]. By using entry points, I don't need
to care what the target system is. Also, /usr/bin/env might invoke
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
At 10:21 AM 5/8/2009 +1200, Noah Gift wrote:
1. Different versions of Python conflict with previous versions of
console scripts. Take paste for example.
I don't understand what you mean.
2. The entry point mechanism IIRC recursively scans the site-packages
directory and loads up the
resending, as I accidently only sent to PJE
On Fri, May 8, 2009 at 11:48 AM, Noah Gift noah.g...@gmail.com wrote:
On Fri, May 8, 2009 at 11:24 AM, P.J. Eby p...@telecommunity.com wrote:
At 10:21 AM 5/8/2009 +1200, Noah Gift wrote:
1. Different versions of Python conflict with previous
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 to find another way to package
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
At 01:14 PM 5/7/2009 -0700, Wheat wrote:
But then having both 'scripts' and 'entry_points/console_scripts' is
less than perfect since it introduces (mostly) unneccessary TIMTOWTDI.
I interpret 'scripts' as meaning non-Python scripts, so there is
still only one obvious way to do each thing.
Paul Moore wrote:
That works but a lot of Unix users have in the past objected to having
'.py' in the name.
So install a symlink from hello - hello.py.
--
Greg
___
Distutils-SIG maillist - Distutils-SIG@python.org
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,
At 10:59 AM 5/6/2009 -0400, Doug Hellmann wrote:
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
Doug Hellmann wrote:
On May 6, 2009, at 1:46 PM, P.J. Eby wrote:
At 10:59 AM 5/6/2009 -0400, Doug Hellmann wrote:
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hanno Schlichting wrote:
Doug Hellmann wrote:
On May 6, 2009, at 1:46 PM, P.J. Eby wrote:
At 10:59 AM 5/6/2009 -0400, Doug Hellmann wrote:
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
At 08:28 PM 5/6/2009 +0200, Hanno Schlichting wrote:
Doug Hellmann wrote:
On May 6, 2009, at 1:46 PM, P.J. Eby wrote:
At 10:59 AM 5/6/2009 -0400, Doug Hellmann wrote:
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
On Wed, May 6, 2009 at 1:32 PM, Tres Seaver tsea...@palladion.com wrote:
I'd be tempted to call this an edge-case. You should be able to expose
the internal detail you'd need via a module scope alias for the
particular case. That seems easier than providing a whole new notion.
I'm
Ian Bicking wrote:
On Wed, May 6, 2009 at 1:32 PM, Tres Seaver tsea...@palladion.com
mailto:tsea...@palladion.com wrote:
I'm actually a big fan of the ':', because it makes explicit the
difference between the import and the named thing, even for
module-scoped names.
Yeah, I
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 since there's no activation with just distutils?
Yes
2009/5/5 P.J. Eby p...@telecommunity.com:
At 06:57 PM 5/4/2009 -0500, Ian Bicking wrote:
* I'm uncomfortable with the way entry points are scanned. I haven't
looked close enough to back it up with numbers, but I think there's a
noticeable performance degradation when the number of installed
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
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 the user to
manually turn a plugin on for an application
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
the
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
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 an
explicit configuration step of some sort.
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
On Tue, May 5, 2009 at 4:29 PM, Doug Hellmann doug.hellm...@gmail.com wrote
I don't think I understand the difference between the step you're calling
discover, scanning the registry, and actually loading the plugin. Does
discovering the plugin involve importing any of its code?
No, like
2009/5/5 Sebastien Binet seb.bi...@gmail.com:
hi,
That allows people to create their own plugins in separate packages,
and use them by tweaking the configuration
file. The only think that entry point provided here is an automatic
registration at installation time of the rss plugins,
so my
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
On Tue, May 05, 2009 at 05:05:28PM +0200, 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 =
At 09:27 PM 5/5/2009 +0100, Floris Bruynooghe wrote:
But how can a python setup.py install know where to find this
configuration file to add it's plugin?
It doesn't. The whole point of having two stages -- discovery and
activation -- is that discovery is an automatic side-effect of
Tarek Ziadé ziade.ta...@gmail.com writes:
I think is simpler with the somepackage.somemodule:MyPluginClass notation
This is how setuptools does roughly:
parts = somepackage.somemodule:MyPluginClass.split(':')
[…]
Using the standard import notation is no more difficult:
parts =
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, function,
or other top-level name within a module. It
Hello
I am making a separate email for this topic to make sure no one misses it.
There are *many* benefits of adding entry points into Distutils. In
fact, adding a plugin system in there,
will help make the commands more extendable and therefore will help us
in the long term to remove things
out
On Tue, 5 May 2009 01:46:21 +0200, Tarek Ziadé ziade.ta...@gmail.com
wrote:
Hello
I am making a separate email for this topic to make sure no one misses
it.
There are *many* benefits of adding entry points into Distutils. In
fact, adding a plugin system in there,
will help make
At 06:57 PM 5/4/2009 -0500, Ian Bicking wrote:
* I'm uncomfortable with the way entry points are scanned. I
haven't looked close enough to back it up with numbers, but I think
there's a noticeable performance degradation when the number of
installed packages becomes large. (Given the
Tarek Ziadé ziade.ta...@gmail.com writes:
There are *many* benefits of adding entry points into Distutils. In
fact, adding a plugin system in there, will help make the commands
more extendable and therefore will help us in the long term to remove
things out of Distutils.
I don't see what
54 matches
Mail list logo
