added setup.py file so that we can install 'q' directly from git or pypi...

[ralhei]

Hi Harel,
just in case you don't mind I have added a setup.py file to your q package. This way it is possible to directly install q from github with

pip install -e git+https://github.com/harelba/q.git#egg=Package

One note: it would be great if you could add a license to 'q', otherwise nobody knows how to handle it from a legal point of view (this includes providing patches etc).

Ciao ciao

Ralph

[harelba]

Hi @ralhei sorry for the late reply,

Thanks a lot for your input and your efforts.

In regard to installing using pip install - While it's another easy way to install q, it collides with my plans regarding q and python. I plan to provide q as a python module so q's capabilities will also be exposed as an API (e.g. import qtextasdata ...), and I treat the command-line variation as "non python specific", meaning that the fact that q is written in python is incidental.

Using pip install for installing the command line variation, although useful, contradicts it. For example, I'm not sure how "uninstalls" are supposed to be performed by pip for q. Another point is that in all other installation forms, q is installed on /usr/bin/q and using pip it seems to be installed in /usr/local/bin/q.

When I make the python module public, I will definitely consider using what you're suggesting here so the q command line can be installed alongside with it.

In regard to the license, you're right that it's not exposed properly. The code does say which license is it, but it's not exposed in the README/site. The license is GPLv3, similar to many command line tools.

Hope you understand the reasoning behind my decision,
Harel

[ralhei]

Hi Harel,

  thanks for your reply. See my comments below.

  On 14.02.15 10:10, Harel Ben-Attia wrote:


  Hi @ralhei sorry for the late reply,
  Thanks a lot for your input and your efforts. 
  In regard to installing using pip install - While it's another
    easy way to install q, it collides with my plans regarding q and
    python. I plan to provide q as a python module so q's
    capabilities will also be exposed as an API (e.g. import
    qtextasdata ...), 

Maybe I'm getting this wrong, but if you plan to provide q as a
python module it makes even more sense to have a python installer.
Otherwise, how would non-python-specialists know where to put the
module so that it is found by the python interpreter???


  and I treat the command-line variation as "non python
    specific", meaning that the fact that q is written in python is
    incidental.
  Using pip install for installing the command line variation,
    although useful, contradicts it. For example, I'm not sure how
    "uninstalls" are supposed to be performed by pip for q. Another
    point is that in all other installation forms, q is installed on
    /usr/bin/q and using pip it seems to be installed in
    /usr/local/bin/q.

Maybe it helps to think of installing q via pip as being equivalent
to install it from the sources which you provide as zip or tar
files. There the user is also free to install things either in
/usr/bin/, /usr/local/bin or whereever. Also, no automatic uninstall
is provided there either. 

From a OS point of view it is rather irrelevant whether binaries are
found in /usr/bin or /usr/local/bin, as the desired effect is that
the user can execute the tool from the command line without worrying
about its location.

There is a 'pip uninstall' feature, however, this indeed does not
remove the q file from in the bin directory. Whether this is a flaw
in my setup file, or a problem with pip, is something that I cannot
answer in the moment.

Having the setup.py file available is - even if you personally
prefer a different way of installing - maybe just another convenient
ways for other users.

For example, in my company, people do not have root access to their
machines. So for them it is extremely helpful to have a way to
install q in a virtual environment. It is a one line command. The
solutions with rpm/dep install won't work, the other ones requires
some additional possibly error prone steps, like
- download the tar.gz file
- unpack it in some locations
- create a virtual env
- find out where the bin directory of the virtual env is (e.g.
~/.virtualenv/<name>/bin)
- copy the q file from the untarred package into
~/.virtualenv/<name>/bin
- cleanup and remove the untarred package

So, you see, compared to pip install -e
  git+https://github.com/harelba/q.git#egg=Package this is a
lot of more work. 
That's why I got inspired to contribute the setup.py file.

But, of course, it's your package and your decision, and I'm
grateful that q exists, it is a really nice tool.

All the best,

Ralph


  When I make the python module public, I will definitely
    consider using what you're suggesting here so the q command line
    can be installed alongside with it.
  In regard to the license, you're right that it's not exposed
    properly. The code does say which license is it, but it's not
    exposed in the README/site. The license is GPLv3, similar to
    many command line tools. 
  Hope you understand the reasoning behind my decision,
    Harel
  —
    Reply to this email directly or view
      it on GitHub.

[harelba]

Hi Ralph,

I see your point about the virtualenv installation.

Also, in regard to my plan of providing a python module - The plan is definitely to provide a pip install method of installing q, but my plan is to change the project structure so it becomes a "standard python module" and not just add setup.py. However, adding a setup.py, perhaps in a subfolder so it doesn't clutter the root project folder, can provide the "pip instlal git://" capability without hurting almost anything.

Also, I'm hardly an expert on python packaging, but i believe that providing an uninstall is probably just adding some stuff to setup.py. I'll take a look at that.

I'll think about it some more and decide what to do.

Thanks for the input
Harel

[ralhei]

Hi Halen,

  thanks for your fast answer.

  On 14.02.15 11:33, Harel Ben-Attia wrote:


  Hi Ralph,
  I see your point about the virtualenv installation. 
  Also, in regard to my plan of providing a python module - The
    plan is definitely to provide a pip install method of installing
    q, but my plan is to change the project structure so it becomes
    a "standard python module" and not just add setup.py. However,
    adding a setup.py, perhaps in a subfolder so it doesn't clutter
    the root project folder, can provide the "pip instlal git://"
    capability without hurting almost anything. 

I've been following discussions of adding new stuff as a standard
python module, very often it is a multi-year process with very
strict and high demands on the new package. E.g. one must ensure
that the API will stable for very long time, and often this is a
very hard thing to guarantee. It might also be rather an obstacle to
further evolve a package. I think there are a few nice blog postings
around which describe this issue.

But thanks for considering adding the setup.py file. Whether one can
put that in a subdir is beyond my knowledge at the moment, I'm not
sure what the search path for pip is within a package. Probably
requires some reading in the docs.

Thanks a again for your considerations,

ciao ciao

Ralph


  Also, I'm hardly an expert on python packaging, but i believe
    that providing an uninstall is probably just adding some stuff
    to setup.py. I'll take a look at that.
  I'll think about it some more and decide what to do.
  Thanks for the input
    Harel
  —
    Reply to this email directly or view
      it on GitHub.

[turtlemonvh]

@ralhei

If you want pip uninstall to work you can change setup.py from

scripts=['bin/q'],

To

entry_points={
    "console_scripts": [
        "q=bin.q:run_standalone"
    ]
}

See the "Automatic script creation" docs for setuptools for more info.

I agree that a setup.py file would be helpful.

[ralhei]

Nice approach - thanks for your hint!