Re: [Gnuplot-py-users] suggestion

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

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

>
>
> On Sun, May 2, 2010 at 12:53 PM, Benny Malengier <
> ben...@gm...> wrote:
>
>>
>>
>> 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?
>>
>
> Actually, setuptools has a bootstrap script  (ez_setup.py) which will
> download and install setuptools if it is not installed. But a try/except
> might also be a good idea since it wouldn't require any extra installation
> for those who download the source tarball manually. As for the ones
> installing via easy_install either directly or as a dependency this is not a
> problem since they've got to have setuptools installed to begin with.
>
>>
>> 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.
>>
>
> Anyone could do the "...sdist register upload", but  ideally it should be
> someone who is also involved with the official releases of Gnuplot.py so
> that the PyPI package is kept up-to-date. The person which uploads the
> initial package becomes the manager of the package in PyPI via their  login
> and password.
>
>
>> 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 have looked at the code of Gnuplot.py and found it to be very readable
> and easy to understand. So if I find the time to improve it, I'll certainly
> post a patch to this list for review.
>
>>
>> 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.
>>
>
> I think that the best way to go too.
>

Ok, I tried it locally.
I have one issue only. There are some defaults in eg Gnuplot/gp_unix.py and
friends users might want to change.

Using setuptools this installs as a zipped egg file however. Is there an
easy way to edit the installed egg? Or does it mean like this users must
install from source to be able to change a default setting? It seems like
that to me.

I can work around it myself with

sudo python setup.py install --single-version-externally-managed
--install-layout=deb --root /

and packagers for ubuntu/... can use that instead of an egg, but people
using easy-install are stuck with our defaults it seems.

Benny


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