best place to put mount information
Erick Tryzelaar
We need to know if a mountpoint is local or the host and path if it's
remote, the space used, the total space, and what are the mount
options. Any recommendations on where to do this? We can parse
/etc/mtab or /proc/mounts on linux and use getmntinfo on the mac
(don't know what to do for the others). I figure we can create
psi.mount.LocalMount and psi.mount.RemoteMount, and create a
"psi.mount.getmounts()" function to pull the data. Does that sound
good, or do you all have a better idea?
Chris Miles
Hadn't thought much about the API for this yet, but I'd like this
functionality too. Your suggestions are a good starting point. To
brainstorm I'd ask:
* Does 'mount' refer to all types of mount points or just filesystem
mounts? OS X has device mount points, for example; there's also
loopback mounts, fuse mounts, /proc, etc.
* Is it always possible to distinguish between local mounts and remote
mounts? iSCSI devices may be remote but look like local LUNs, for
example.
* Can we specify types of mounts to return? e.g. request only mount
points of type 'ext3'.
At the very least, I'd like to be able to get all the filesystem mount
points from PSI. On Linux, 'df' returns less mount points than
'mount', so presumably there's some logic to differentiate real
filesystems (size?).
Cheers,
Chris
Erick Tryzelaar
>
> Hadn't thought much about the API for this yet, but I'd like this
> functionality too. Your suggestions are a good starting point. To
> brainstorm I'd ask:
>
> * Does 'mount' refer to all types of mount points or just filesystem
> mounts? OS X has device mount points, for example; there's also
> loopback mounts, fuse mounts, /proc, etc.
For my purposes, we just need what's outputted in "mount". I've got no
problems with it being more expansive though.
> * Is it always possible to distinguish between local mounts and remote
> mounts? iSCSI devices may be remote but look like local LUNs, for
> example.
I'm not familiar with how they're mounted, but it could be nice if
that was discoverable.
> * Can we specify types of mounts to return? e.g. request only mount
> points of type 'ext3'.
I don't see why not.
> At the very least, I'd like to be able to get all the filesystem mount
> points from PSI. On Linux, 'df' returns less mount points than
> 'mount', so presumably there's some logic to differentiate real
> filesystems (size?).
That's a good point, I wonder what df is doing differently.
Erick Tryzelaar
support for darwin tomorrow. Feel free to hack it up.
Chris Miles
On 28/05/2009, at 5:42 PM, Erick Tryzelaar wrote:
> Okay, I committed a version that supports linux. I'll try to add
> support for darwin tomorrow. Feel free to hack it up.
Cool. Can you try to make sure that it still compiles on systems
where mount (or any new feature) hasn't yet been implemented? No
doubt there will be systems that lag behind new feature
implementations, but the rest of the library should still work.
At run-time, systems that don't have a feature ported to it yet should
raise an appropriate exception.
Cheers,
Chris
Erick Tryzelaar
>
> Cool. Can you try to make sure that it still compiles on systems
> where mount (or any new feature) hasn't yet been implemented? No
> doubt there will be systems that lag behind new feature
> implementations, but the rest of the library should still work.
I did, I modified the setup.py to not build the module on non-linux
platforms. For exposing it in psi/__init__.py, I catch the ImportError
when accessing psi.module and ignore it. Hopefully this was
sufficient. It at least allowed darwin to build and run.
> At run-time, systems that don't have a feature ported to it yet should
> raise an appropriate exception.
That's even better. NotImplementedError?
Chris Miles
On 28/05/2009, at 5:57 PM, Erick Tryzelaar wrote:
>
> On Thu, May 28, 2009 at 12:51 AM, Chris Miles
> <miles...@gmail.com> wrote:
>>
>> Cool. Can you try to make sure that it still compiles on systems
>> where mount (or any new feature) hasn't yet been implemented? No
>> doubt there will be systems that lag behind new feature
>> implementations, but the rest of the library should still work.
>
> I did, I modified the setup.py to not build the module on non-linux
> platforms. For exposing it in psi/__init__.py, I catch the ImportError
> when accessing psi.module and ignore it. Hopefully this was
> sufficient. It at least allowed darwin to build and run.
Cool.
>> At run-time, systems that don't have a feature ported to it yet
>> should
>> raise an appropriate exception.
>
> That's even better. NotImplementedError?
Sounds good to me.
Cheers
Chris
Floris Bruynooghe
>
> Any recommendations on where to do this? We can parse
> /etc/mtab or /proc/mounts on linux
There's also a (g)libc API for /etc/mtab. I don't know which would be
better to use or if there's even other ways.
Floris
--
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
Floris Bruynooghe
>
> On Thu, May 28, 2009 at 12:51 AM, Chris Miles <miles...@gmail.com> wrote:
> >
> > Cool. Can you try to make sure that it still compiles on systems
> > where mount (or any new feature) hasn't yet been implemented? No
> > doubt there will be systems that lag behind new feature
> > implementations, but the rest of the library should still work.
>
> I did, I modified the setup.py to not build the module on non-linux
> platforms. For exposing it in psi/__init__.py, I catch the ImportError
> when accessing psi.module and ignore it. Hopefully this was
> sufficient. It at least allowed darwin to build and run.
The idea I had in my head about dealing with new features was by
developing them in separate (logical) modules. But don't actually
import them to the psi namespace until they're stable. I also thought
using a FeatureWarning at import time would be good for these modules
until we're sure we want to commit to the API.
> > At run-time, systems that don't have a feature ported to it yet should
> > raise an appropriate exception.
>
> That's even better. NotImplementedError?
Yep, sounds good. Platforms not yet having features raise
NotImplementedError (either at module import time or when invoking a
function). Ideally we should try to add all platforms before making a
module stable (removing the FutureWarning and importing it
automatically into the psi namespace) but I guess that will not scale
in the end so we might end up with a hybrid approach where we can have
stable API's that still have NotImplementedErrors on some platforms.
(For the record I've got a "host" module locally that has classes for
CPU and NIC information and statistics. Once that is actually
partially usable I was thinking of committing that into a branch.)
Regards
Erick Tryzelaar
<floris.b...@gmail.com> wrote:
>
> The idea I had in my head about dealing with new features was by
> developing them in separate (logical) modules. But don't actually
> import them to the psi namespace until they're stable. I also thought
> using a FeatureWarning at import time would be good for these modules
> until we're sure we want to commit to the API.
I wonder as psi grows if we even should be automatically importing
these libraries in psi/__init__.py. I assume it'd be a little faster
on initial import if we only imported what we needed. Then we can be
more carefree with creating new modules since we'd only build them on
systems that supported it, and get ImportErrors on the rest.
> (For the record I've got a "host" module locally that has classes for
> CPU and NIC information and statistics. Once that is actually
> partially usable I was thinking of committing that into a branch.)
Please do! That was the next thing I needed.
Chris Miles
On 29/05/2009, at 4:20 AM, Floris Bruynooghe wrote:
> The idea I had in my head about dealing with new features was by
> developing them in separate (logical) modules. But don't actually
> import them to the psi namespace until they're stable. I also thought
> using a FeatureWarning at import time would be good for these modules
> until we're sure we want to commit to the API.
I like that strategy. I can imagine we will need to go back and forth
on design decisions for some modules until we agree on a suitable API.
We could also perhaps group them under a "future" (or "__future__")
space, like Python does, until the API is stabilised. "from
psi.future import mount" ..? *shrug*
>
>
>>> At run-time, systems that don't have a feature ported to it yet
>>> should
>>> raise an appropriate exception.
>>
>> That's even better. NotImplementedError?
>
> Yep, sounds good. Platforms not yet having features raise
> NotImplementedError (either at module import time or when invoking a
> function). Ideally we should try to add all platforms before making a
> module stable (removing the FutureWarning and importing it
> automatically into the psi namespace) but I guess that will not scale
> in the end so we might end up with a hybrid approach where we can have
> stable API's that still have NotImplementedErrors on some platforms.
In reality I can't see all modules being stabilised for all supported
platforms all the time. So the hybrid approach makes sense to me.
>
> (For the record I've got a "host" module locally that has classes for
> CPU and NIC information and statistics. Once that is actually
> partially usable I was thinking of committing that into a branch.)
Excellent. yes please.
Cheers,
Chris
Floris Bruynooghe
>
> On 29/05/2009, at 4:20 AM, Floris Bruynooghe wrote:
>
> > The idea I had in my head about dealing with new features was by
> > developing them in separate (logical) modules. But don't actually
> > import them to the psi namespace until they're stable. I also thought
> > using a FeatureWarning at import time would be good for these modules
> > until we're sure we want to commit to the API.
>
> I like that strategy. I can imagine we will need to go back and forth
> on design decisions for some modules until we agree on a suitable API.
>
> We could also perhaps group them under a "future" (or "__future__")
> space, like Python does, until the API is stabilised. "from
> psi.future import mount" ..? *shrug*
Python does that for languate features, not for APIs. Problem is that
the old pre-stabilised way needs to keep working, when simply using a
FutureWarning the old code will happiliy keep working, it is only
suppressing a warning that is no longer present. While if we make a
"future" module we have to start providing the module in two places
which seems messier to me.
I'm quite up for Erick's idea of not importing modules by default even
after they're stable (with maybe exceptions for arch and process).
Erick Tryzelaar
<floris.b...@gmail.com> wrote:
>
> I'm quite up for Erick's idea of not importing modules by default even
> after they're stable (with maybe exceptions for arch and process).
Chris, are you okay with this? I'm not sure if that's what you meant by:
> I like that strategy. I can imagine we will need to go back and forth
> on design decisions for some modules until we agree on a suitable API.
If so, I'll remove:
import psi.arch as arch
import psi.process as process
from psi/__init__.py.
Floris Bruynooghe
Whoa, not quite sure if I'm sure about this yet, but I could be
convinced. I must admit I don't have much experience with other
namespace packages and don't know the "normal" bahviour in this case.
Chris Miles
I thought we wouldn't import unstable/future modules by default, but
stable modules would be imported into psi namespace as they are now.
Is there a reason not to import all stable modules into psi
namespace? Are we worried about size?
Cheers
Chris
Erick Tryzelaar
>
> I thought we wouldn't import unstable/future modules by default, but
> stable modules would be imported into psi namespace as they are now.
>
> Is there a reason not to import all stable modules into psi
> namespace? Are we worried about size?
Two reasons I can think of. First, I think it's just a little
inconsistent. For instance, if python doesn't have a C version of a
library, they don't create a dummy object, they just handle the
ImportError to fall back on another module. I think that'd work fine
for us.
Second, it's nicer getting an ImportError when you import psi.mount,
than getting an AttributeError when importing psi and accessing
psi.mount. It'd be easier to handle in code. I'm also now starting to
think that ImportError is a better exception than raising
NotImplementedError on import. I think that's really supposed to be
for another class of errors.
Chris Miles
Ok, those arguments for import-on-demand sound reasonable to me. The
behaviour is transparent from the user point-of-view right (assuming
no import errors)?
Re NotImplementedError vs ImportError: I like NotImplementedError to
represent "this module is not yet available but we plan for it to be
soon..." kind of thing; whereas ImportError is really stating "You
messed up your import mate".
Having said that, I don't know if there's any precedent for returning
anything but ImportError if the module doesn't exist. Perhaps
ImportError is "The Right Thing" to raise...
Cheers
Chris
Erick Tryzelaar
>
> Ok, those arguments for import-on-demand sound reasonable to me. The
> behaviour is transparent from the user point-of-view right (assuming
> no import errors)?
So just to be clear, you're now okay with making users do "import
psi.process"? And Floris, you are as well?
> Re NotImplementedError vs ImportError: I like NotImplementedError to
> represent "this module is not yet available but we plan for it to be
> soon..." kind of thing; whereas ImportError is really stating "You
> messed up your import mate".
>
> Having said that, I don't know if there's any precedent for returning
> anything but ImportError if the module doesn't exist. Perhaps
> ImportError is "The Right Thing" to raise...
I'm not aware of any, and I think there's precedent for just allowing
the ImportError if the module isn't supported. I think the Warning's a
good idea to say "this module is in progress and isn't done", which
does convey what you want, just from another angle. Does that create
the effect you're looking for?
Floris Bruynooghe
>
> On Mon, Jun 1, 2009 at 8:21 PM, Chris Miles <miles...@gmail.com> wrote:
> >
> > Ok, those arguments for import-on-demand sound reasonable to me. The
> > behaviour is transparent from the user point-of-view right (assuming
> > no import errors)?
>
> So just to be clear, you're now okay with making users do "import
> psi.process"? And Floris, you are as well?
I guess it's more consistent. So yes, why not.
> > Re NotImplementedError vs ImportError: I like NotImplementedError to
> > represent "this module is not yet available but we plan for it to be
> > soon..." kind of thing; whereas ImportError is really stating "You
> > messed up your import mate".
> >
> > Having said that, I don't know if there's any precedent for returning
> > anything but ImportError if the module doesn't exist. Perhaps
> > ImportError is "The Right Thing" to raise...
>
> I'm not aware of any, and I think there's precedent for just allowing
> the ImportError if the module isn't supported. I think the Warning's a
> good idea to say "this module is in progress and isn't done", which
> does convey what you want, just from another angle. Does that create
> the effect you're looking for?
Hmm, I don't want NotImplementedErrors on import. I rather think that
every module should be importable on each platform and if it's not
implemented yet the individual functions/classes are skeletongs that
just raise NotImplementedErrors. Much like psi.host.NetifInfo() and
NetifStats() are currently (I need to add the darwin skeletons).
Floris Bruynooghe
> Hmm, I don't want NotImplementedErrors on import. I rather think that
> every module should be importable on each platform and if it's not
> implemented yet the individual functions/classes are skeletongs that
> just raise NotImplementedErrors. Much like psi.host.NetifInfo() and
> NetifStats() are currently (I need to add the darwin skeletons).
I've added something like this in the DESIGN file. Could you check
that makes sense and everyone agrees with it? Feel free to edit,
complain etc.
Cheers
Floris
Chris Miles
On 03/06/2009, at 10:06 AM, Floris Bruynooghe wrote:
>
> On Tue, Jun 02, 2009 at 06:58:06PM +0100, Floris Bruynooghe wrote:
>> Hmm, I don't want NotImplementedErrors on import. I rather think
>> that
>> every module should be importable on each platform and if it's not
>> implemented yet the individual functions/classes are skeletongs that
>> just raise NotImplementedErrors. Much like psi.host.NetifInfo() and
>> NetifStats() are currently (I need to add the darwin skeletons).
>
> I've added something like this in the DESIGN file. Could you check
> that makes sense and everyone agrees with it? Feel free to edit,
> complain etc.
Ok, the policy in DESIGN sounds reasonable to me. Makes sense.
Chris
Floris Bruynooghe
> At the very least, I'd like to be able to get all the filesystem mount
> points from PSI. On Linux, 'df' returns less mount points than
> 'mount', so presumably there's some logic to differentiate real
> filesystems (size?).
Filtering on total size of 0 is what generally is done to get rid of
all the "special" mounts (also on Solaris btw). But I don't think psi
needs to worry about that (staying close to the kernel and all that),
maybe a hint in a docstring is more appropriate.