Re: [Gnuplot-py-users] suggestion

[Benny M. <ben...@gm...>]

2010/5/2 Flavio Coelho <fcc...@gm...>

>
>
> On Sun, May 2, 2010 at 9:41 AM, Benny Malengier <ben...@gm...
> > wrote:
>
>>
>>
>> 2010/4/26 Flavio Coelho <fcc...@gm...>
>>
>> Hi,
>>>
>>> I use Gnuplot.py in some of my projects, and would like to thank Michael
>>> for such a useful package.
>>>
>>> One of my projects, Liveplots[1], depends on Gnuplot.py, and uses
>>> setuptools (easy_install)[2] as its main mode of distribution. It would be
>>> very convenient for me, and possibly for other Gnuplot.py users, that is
>>> could also be installed by means of the easy_install command. This is
>>> important because other projects which want to declare Gnuplot.py as a
>>> dependency can do so by listing it in their setup.py and have it be
>>> installed automatically.
>>>
>>> To enable this, all that is required is to edit one line in the setup.py:
>>>
>>>
>>> where it reads "from distutils.core import setup"  it should read: "from
>>> setuptools import setup". After this, running "python setup.py sdist.
>>> register upload", will add Gnuplot.py to Python Package Index and make it
>>> easy_installable for users with setuptools installed.
>>>
>>> I should also point out, that this edit will not affect in any way how
>>> Gnuplot.py is currently used and installed, just add a new way to install
>>> it.
>>>
>>
>> This seems easy, but is it the correct way forward? I did not follow all
>> the dirt being thrown around with respect to building/installing python
>> pacages. I know there is a lot of controversies.
>> However, distutils remains supported in python core
>> http://docs.python.org/distutils/index.html#distutils-index
>>
>> so it is a part of python 3. People still seem to use it and advocate it
>> (eg http://diveintopython3.org/packaging.html ).
>>
>> So, why not use the core packages? If we go with setuptools, we could also
>> take pip or distribute...
>>
>
> I have followed some of the discussion regarding the fork of Distribute
> from setuptools, and the issues at the core where about how to make the
> package evolve towards being included in the standard library, not about its
> usefulness. Neither Setuptools or Distribute mean to replace distutils but
> to extend it. Making a setup.py compatible with setuptools or Distribute,
> does not affect the "python setup.py install" way of installing packages of
> distutils. But it allows for packages to declare a dependency tree of
> packages, which is not available in plain distutils.
>
> Moreover, most heavily used python packages have been using setuptools for
> years. So the bottom line is that adopting setuptools costs just a couple of
> line edits in setup.py while being  completely transparent to users
> accustomed to distutils. There's much to gain and nothing to loose.
>
>
So I assume you mean that gnuplot could use a  try except block for this
import, or would you aim at making setuptools a dependency?

What is actually the standard about running
python setup.py sdist. register upload
The main developer should do it? Problem is a bit that Michael still replies
mails to mailing list from time to time, but there is at the time nobody
with the time to actually hack at Gnuplot.py.
If you build on top of gnuplot, you might be interested in exposing some of
the new capabilities of gnuplot in the Gnuplot.py API?
It is great that we have the API to directly pass gnuplot commands, but it
does mean not many people are interested in expanding the API.

I don't mind doing this change in the code myself, I use an extension to
setuptools for one of my own projects, but I'd like Michael to agree with it
before adding it, as I have only done some very small contributions up to
now.

Benny

cheers,
>
> Flávio
>
>
>
> --
> Flávio Codeço Coelho
>
>