On Jul 30, 2011 12:07 PM, "Lisandro Dalcin" <dalcinl@gmail.com> wrote:
> On 25 July 2011 19:33, Jed Brown <jedbrown@mcs.anl.gov> wrote:
>> On Mon, Jul 25, 2011 at 10:16, Ethan Coon <ecoon@lanl.gov> wrote:
>>>
>>> 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.
>>
>> Making the user/scripts do manual sys.path or PYTHONPATH manipulation makes
>> it nearly impossible to make portable scripts that depend on these
>> functions. Should we start a "proper" Python package containing PETSc
>> utilities? Then scripts could rely on
>> from petsc.io import binary_read
>> or whatever working. Of course it might only contain two functions right
>> now, but I could add my "petscplot" (makes various types of convergence and
>> scaling plots from convergence monitors and -log_summary output), and I'm
>> sure the community has other useful scripts.
>
> Note however that "petsc" package is already registered in PyPI to
> make "pip install petsc4py" download and install PETSc.
>
>
> --
> Lisandro Dalcin
> ---------------
> CIMEC (INTEC/CONICET-UNL)
> Predio CONICET-Santa Fe
> Colectora RN 168 Km 472, Paraje El Pozo
> 3000 Santa Fe, Argentina
> Tel: +54-342-4511594 (ext 1011)
> Tel/Fax: +54-342-4511169