[petsc-dev] [petsc-maint #80119] Re: make install broken on unix?

Ethan Coon ecoon at lanl.gov
Mon Jul 25 12:16:27 CDT 2011

On Mon, 2011-07-25 at 17:06 +0000, Matthew Knepley wrote:
> On Mon, Jul 25, 2011 at 4:56 PM, Sean Farley <sean at mcs.anl.gov> wrote:
>                 I disagree with this completely.  There's a tendency
>                 to think of everything python as a package -- this is
>                 NOT a package.  It has no __init__.py, it has no
>                 __all__, it has no submodules, and it doesn't need any
>                 of that.  It simply does a one-off task -- it's bits
>                 of code to be used in a script.  Putting this sort of
>                 code in site-packages is what makes site-packages the
>                 nightmare of ignored dependencies and overlapping
>                 versions it is today.
>                 If you want to make it into a package, you're welcome
>                 to do so.  With that includes registration with the
>                 cheeseshop to make sure the namespace is unique,
>                 placing the single file within a folder that includes
>                 an __init__ (and then likely just gets imported within
>                 that __init__), writing a setup.py, etc etc.  It's
>                 just complete overkill.
>         Then why put it in bin/python at all? Just drop the .py
>         extension and put it in bin (with a 'correct' [whatever that
>         may be] python hashbang)?
> I am for this, although I do not give a crap what the extension is.

Barry didn't want it in bin if it was going to have multiple files.  Maybe it should just go in bin/PetscBinaryIO.py and when I get around to adding the "write" functionality it can be included in the same file?  

It's not really a stand-alone script though, so it shouldn't get the hashbang or lose the extension.  But it's not a full-fledged package of libraries either.  I don't think it should be anywhere in the default path -- it's the kind of code that you should have to explicitly include (either via sys.path manipulation or via PYTHONPATH) because too many little scripts of utility code makes for a nasty, polluted namespace.  There just isn't a good place (that I know of) in the standard file system hierarchy for this kind of stuff.


>    Matt
>         Sean
> -- 
> What most experimenters take for granted before they begin their
> experiments is infinitely more interesting than any results to which
> their experiments lead.
> -- Norbert Wiener

Ethan Coon
Post-Doctoral Researcher
Applied Mathematics - T-5
Los Alamos National Laboratory


More information about the petsc-dev mailing list