In article <4c56d814.4030...@voidspace.org.uk>,
Michael Foord wrote:
> Ronald was wrong when he said that the only configuration file in ~ used
> by the Mac itself is .CFUserTextEncoding. Terminal (the Mac OS X command
> line) has a user editable config file which it stores in ~.
Terminal.app
Michael Foord writes:
> I would be interested in hearing from other Mac users as to where they
> would look for configuration files for command line tools - in ~ or in
> ~/Library/Preferences?
My primary personal machine has been OSX for years now, and as someone
who lives in the command line (w
On 2 Aug, 2010, at 16:24, R. David Murray wrote:
> (Ronald, the text version of your message was very difficult to sort
> through and read, because all of the quoting information was lost.
> Just thought you'd want to know.)
I'll stop using the mobile-me webmail client for lists, it seems to mes
On 02/08/2010 15:24, R. David Murray wrote:
(Ronald, the text version of your message was very difficult to sort
through and read, because all of the quoting information was lost.
Just thought you'd want to know.)
What I hear Glyph saying is that we should support looking in *both*
locations for
(Ronald, the text version of your message was very difficult to sort
through and read, because all of the quoting information was lost.
Just thought you'd want to know.)
What I hear Glyph saying is that we should support looking in *both*
locations for configuration info on OSX, and I don't see a
On 02/08/2010 14:34, Ronald Oussoren wrote:
On 02 Aug, 2010,at 01:00 PM, Michael Foord
wrote:
> The only apple one that is actually used is the .CFUserTextEncoding
> file, I have an .Xcode in my home as well but that is empty and last
> updated in 2007. AFAIK current versions of Xcode stor
On 02/08/2010 14:34, Ronald Oussoren wrote:
On 02 Aug, 2010,at 01:00 PM, Michael Foord
wrote:
> The only apple one that is actually used is the .CFUserTextEncoding
> file, I have an .Xcode in my home as well but that is empty and last
> updated in 2007. AFAIK current versions of Xcode stor
On 02 Aug, 2010,at 01:00 PM, Michael Foord wrote:
> The only apple one that is actually used is the .CFUserTextEncoding
> file, I have an .Xcode in my home as well but that is empty and last
> updated in 2007. AFAIK current versions of Xcode store preferences in
> ~/Library/Preferences. Most of
On 02/08/2010 11:48, Ronald Oussoren wrote:
On 02 Aug, 2010,at 11:48 AM, Michael Foord
wrote:
On 02/08/2010 07:18, Ronald Oussoren wrote:
On 2 Aug, 2010, at 7:18, Glyph Lefkowitz wrote:
On Aug 1, 2010, at 3:52 PM, Ronald Oussoren wrote:
On 1 Aug, 2010, at 17:22, Éric Araujo
On 02/08/2010 11:48, Ronald Oussoren wrote:
On 02 Aug, 2010,at 11:48 AM, Michael Foord
wrote:
On 02/08/2010 07:18, Ronald Oussoren wrote:
On 2 Aug, 2010, at 7:18, Glyph Lefkowitz wrote:
On Aug 1, 2010, at 3:52 PM, Ronald Oussoren wrote:
On 1 Aug, 2010, at 17:22, Éric Araujo
On 02 Aug, 2010,at 11:48 AM, Michael Foord wrote:
On 02/08/2010 07:18, Ronald Oussoren wrote:
On 2 Aug, 2010, at 7:18, Glyph Lefkowitz wrote:
On Aug 1, 2010, at 3:52 PM, Ronald Oussoren wrote:
On 1 Aug, 2010, at 17:22, Éric Araujo wrote:
On Sun, 01 Aug 2010 17:22:55 +0200
Éric Araujo wrote:
> > Speaking of which... Your documentation says it's named ~/unittest.cfg,
> > could you make this a file in the user base (that is, the prefix where
> > 'setup.py install --user' will install files)?
>
> Putting .pydistutils.cfg .pypirc .uni
On 02/08/2010 07:18, Ronald Oussoren wrote:
On 2 Aug, 2010, at 7:18, Glyph Lefkowitz wrote:
On Aug 1, 2010, at 3:52 PM, Ronald Oussoren wrote:
On 1 Aug, 2010, at 17:22, Éric Araujo wrote:
Speaking of which... Your documentation says it's named ~/unittest.cfg,
could you mak
Glyph Lefkowitz wrote:
I'd say that since ~/Library/Python is already used, there's no
particular reason to add a new ~/Library/Preferences/Python location.
I think the reason for separating out Preferences is so
that you can install a new version of a library or application
without losing the
On 2 Aug, 2010, at 7:18, Glyph Lefkowitz wrote:
>
> On Aug 1, 2010, at 3:52 PM, Ronald Oussoren wrote:
>
>>
>> On 1 Aug, 2010, at 17:22, Éric Araujo wrote:
>>
Speaking of which... Your documentation says it's named ~/unittest.cfg,
could you make this a file in the user base (that is
On Aug 1, 2010, at 3:52 PM, Ronald Oussoren wrote:
>
> On 1 Aug, 2010, at 17:22, Éric Araujo wrote:
>
>>> Speaking of which... Your documentation says it's named ~/unittest.cfg,
>>> could you make this a file in the user base (that is, the prefix where
>>> 'setup.py install --user' will install
On 1 Aug, 2010, at 17:22, Éric Araujo wrote:
>> Speaking of which... Your documentation says it's named ~/unittest.cfg,
>> could you make this a file in the user base (that is, the prefix where
>> 'setup.py install --user' will install files)?
>
> Putting .pydistutils.cfg .pypirc .unittest2.cfg
On 01/08/2010 18:38, R. David Murray wrote:
On Sun, 01 Aug 2010 17:22:55 +0200, wrote:
Speaking of which... Your documentation says it's named ~/unittest.cfg,
could you make this a file in the user base (that is, the prefix where
'setup.py install --user' will install files)?
Putti
On Sun, 01 Aug 2010 17:22:55 +0200, wrote:
> > Speaking of which... Your documentation says it's named ~/unittest.cfg,
> > could you make this a file in the user base (that is, the prefix where
> > 'setup.py install --user' will install files)?
>
> Putting .pydistutils.cfg .pypirc .unittest2.cfg
> Speaking of which... Your documentation says it's named ~/unittest.cfg,
> could you make this a file in the user base (that is, the prefix where
> 'setup.py install --user' will install files)?
Putting .pydistutils.cfg .pypirc .unittest2.cfg .idlerc and possibly
other in the user home directory
On 31 Jul, 2010, at 13:57, Michael Foord wrote:
> On 31/07/2010 12:46, Michael Foord wrote:
>> [snip...]
>> If PEP 376 goes ahead then we could keep the user plugin
>
> I meant "keep the user config file".
Speaking of which... Your documentation says it's named ~/unittest.cfg, could
you make
>> Note that the PEP 376 implementation is mainly done in pkgutil. A
>> custom version lives in distutils2 but
>> when ready, will be pushed independently in pkgutil
>
> Ok. It would be helpful for unittest2 (the backport) if it was *still*
> available in distutils2 even after the merge into pkgu
On 31/07/2010 17:22, Tarek Ziadé wrote:
On Sat, Jul 31, 2010 at 1:46 PM, Michael Foord
wrote:
...
Installation of plugins would still be done through the standard
distutils(2) machinery. (Using PEP 376 would depend on distutils2. I would
be fine with this.)
Note that the PEP 376 imp
On Sat, Jul 31, 2010 at 1:46 PM, Michael Foord
wrote:
...
>
> Installation of plugins would still be done through the standard
> distutils(2) machinery. (Using PEP 376 would depend on distutils2. I would
> be fine with this.)
Note that the PEP 376 implementation is mainly done in pkgutil. A
custo
On 31/07/2010 12:46, Michael Foord wrote:
[snip...]
If PEP 376 goes ahead then we could keep the user plugin
I meant "keep the user config file".
Michael
and use the PEP 376 metadata, in concert with a user config file, to
discover all plugins *available*. A plugins subcommand could then
a
On 31/07/2010 01:51, David Cournapeau wrote:
On Fri, Jul 30, 2010 at 10:23 PM, Michael Foord
wrote:
For those of you who found this document perhaps just a little bit too long,
I've written up a *much* shorter intro to the plugin system (including how
to get the prototype) on my blog:
2010/7/31 David Cournapeau :
> On Fri, Jul 30, 2010 at 10:23 PM, Michael Foord
> wrote:
>> For those of you who found this document perhaps just a little bit too long,
>> I've written up a *much* shorter intro to the plugin system (including how
>> to get the prototype) on my blog:
>>
>> http:
On Sat, Jul 31, 2010 at 12:34 AM, Michael Foord
wrote:
> Explicit registration over implicit registration by subclassing is an
> interesting discussion, but I like the simplicity provided by just
> subclassing.
Note that ABCs are deliberately designed to let *users* choose to do
either. Subclassi
On Fri, Jul 30, 2010 at 10:23 PM, Michael Foord
wrote:
> For those of you who found this document perhaps just a little bit too long,
> I've written up a *much* shorter intro to the plugin system (including how
> to get the prototype) on my blog:
>
> http://www.voidspace.org.uk/python/weblog/a
At 04:37 PM 7/30/2010 +0200, Tarek Ziadé wrote:
On Fri, Jul 30, 2010 at 4:04 PM, Barry Warsaw wrote:
..
> * Registration - How do third party plugins declare themselves to
exist, and
> be enabled? Part of this seems to me to include interface declarations
> too. Is installation of the plug
On 30/07/2010 21:56, P.J. Eby wrote:
At 03:34 PM 7/30/2010 +0100, Michael Foord wrote:
Automatic discoverability, a-la setuptools entry points, is not
without its problems though. Tarek outlines some of these in a more
recent blog post:
FWIW, it's not discovery that's the problem, but configu
At 03:34 PM 7/30/2010 +0100, Michael Foord wrote:
Automatic discoverability, a-la setuptools entry points, is not
without its problems though. Tarek outlines some of these in a more
recent blog post:
FWIW, it's not discovery that's the problem, but configuring *which*
plugins you wish to have
On Fri, Jul 30, 2010 at 5:54 PM, Éric Araujo wrote:
>> It has an API, but the plugins are not interface based (so interface
>> requirements don't need to be part of the plugin system).
>
> Oh, I see. With duck-typing and ABCs, I don’t make a difference between
> protocols and interfaces in my head
On Jul 30, 2010, at 6:23 AM, Michael Foord wrote:
> For those of you who found this document perhaps just a little bit too long,
> I've written up a *much* shorter intro to the plugin system (including how to
> get the prototype) on my blog:
>
> http://www.voidspace.org.uk/python/weblog/ar
> It has an API, but the plugins are not interface based (so interface
> requirements don't need to be part of the plugin system).
Oh, I see. With duck-typing and ABCs, I don’t make a difference between
protocols and interfaces in my head :) Also, the I in API does mean
interface, but not imply b
On 30/07/2010 16:28, Éric Araujo wrote:
Le 30/07/2010 17:04, Michael Foord a écrit :
There is no type checking or interface requirements in my plugin
proposal for unittest. It is essentially an event based system.
Event-based sounds good. unittest2 does have an interface IMO:
configur
Le 30/07/2010 17:04, Michael Foord a écrit :
> There is no type checking or interface requirements in my plugin
> proposal for unittest. It is essentially an event based system.
Event-based sounds good. unittest2 does have an interface IMO:
configuration loading, plugin registration/activation, s
On 30/07/2010 15:41, Marty Alchin wrote:
This is my first post to python-dev, so for those who might not know
me, I'm the author of Pro Django and more recently, Pro Python.
I haven't looked at the plugin landscape in a while, but I was very
disappointed the last time I looked at how complex typ
On 30/07/2010 15:37, Tarek Ziadé wrote:
On Fri, Jul 30, 2010 at 4:04 PM, Barry Warsaw wrote:
..
* Registration - How do third party plugins declare themselves to exist, and
be enabled? Part of this seems to me to include interface declarations
too. Is installation of the plugin enough
On Fri, Jul 30, 2010 at 4:34 PM, Michael Foord
wrote:
...
> Again I think the *needs* of unittest and distutils are different, so I
> wonder if a single system can usefully suit both our needs (let alone
> universally support other systems). Definitely an area worth exploring
> though.
Yes, even
This is my first post to python-dev, so for those who might not know
me, I'm the author of Pro Django and more recently, Pro Python.
I haven't looked at the plugin landscape in a while, but I was very
disappointed the last time I looked at how complex typical systems
were in this regard. There see
On Fri, Jul 30, 2010 at 4:04 PM, Barry Warsaw wrote:
> You guys should definitely write up a plugin PEP!
I am all for it, I am pretty sure we can come up with a generic tool
that can be useful for many packages in the stdlib
Starting this...
--
Tarek Ziadé | http://ziade.org
On Fri, Jul 30, 2010 at 4:04 PM, Barry Warsaw wrote:
..
> * Registration - How do third party plugins declare themselves to exist, and
> be enabled? Part of this seems to me to include interface declarations
> too. Is installation of the plugin enough to register it? How do end users
> enabl
On 30/07/2010 15:04, Barry Warsaw wrote:
On Jul 30, 2010, at 11:38 AM, Michael Foord wrote:
I'm going to read your blog entry on the topic to evaluate it properly
though:
https://tarekziade.wordpress.com/2009/05/01/basic-plugin-system-using-abcs-
and-the-extensions-package/
Very int
On Jul 30, 2010, at 11:38 AM, Michael Foord wrote:
>I'm going to read your blog entry on the topic to evaluate it properly
>though:
>
>https://tarekziade.wordpress.com/2009/05/01/basic-plugin-system-using-abcs-
>and-the-extensions-package/
Very interesting. For Mailman 3, I have YAPS (yet anothe
For those of you who found this document perhaps just a little bit too long,
I've written up a *much* shorter intro to the plugin system (including how
to get the prototype) on my blog:
http://www.voidspace.org.uk/python/weblog/arch_d7_2010_07_24.shtml#e1186
Michael
On 29 July 2010 23:55, Mi
On 30/07/2010 11:09, Tarek Ziadé wrote:
On Fri, Jul 30, 2010 at 12:55 AM, Michael Foord
wrote:
...
The Plugin Class
A sometimes-more-convenient way of creating plugins is to subclass the
``unittest2.events.Plugin`` class. By default subclassing ``Plugin`` will
auto-instan
On Fri, Jul 30, 2010 at 12:55 AM, Michael Foord
wrote:
...
>
> The Plugin Class
>
>
> A sometimes-more-convenient way of creating plugins is to subclass the
> ``unittest2.events.Plugin`` class. By default subclassing ``Plugin`` will
> auto-instantiate the plugin and store the inst
Damn, the email was truncated. Probably my fault. The part missed off is:
Not Yet Implemented
===
Except where noted, everything in this document is already working in
the prototype. There are a few open issues and things still to be
implemented.
Certain event attributes sho
49 matches
Mail list logo
