hhroc / traffairious

Traffic v.s. Air Quality data visualization experiments for http://HackUpstate.com

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Incorrect Usage of setup.py

citruspi opened this issue · comments

setup.py

Up till this point, the project has been using a setup.py file to facilitate the installation of dependencies. This is not the correct way to handle dependencies, especially the way they're being handled right now.

What do I mean by that? There are two problems with what's happening right now.

  1. Modules, Packages, and Applications

    Traditionally, setup.py has been used to distribute modules and packages which will be used by other applications. This allows users to run

    python setup.py install
    

    and have the module or package installed along with its dependencies. Traffairious is not a module or a package which will be used by other applications - setup.py is overkill and incorrect.

  2. Dependency Versions

    The other problem with the current method of managing dependencies is that it doesn't account for new versions of dependencies which break code - the current setup.py doesn't specify required versions. For example, the current file includes

    ...
    install_requires=[
       "flask",
    ...
    

    which basically says "install the latest version of the package 'flask.'" When I install the dependencies on my development environment using setup.py right now, I would get flask version 0.10.1. What would happen if by the time I pushed it to the production server, flask version 0.11 had been released - and the release broke traffairious' existing code? setup.py would install the latest version (i.e. 0.11) and traffairious would crash. To avoid this, applications (as well as modules and packages) should specify the correct version of the dependency to install.

requirements.txt

As I mentioned previously, the correct method of handling dependencies in the case of an application is a requirements.txt file which lists the required dependencies as well as the required version.

The requirements.txt for this project, at the time of writing this, is

Flask==0.10.1
Flask-Compress==1.0.0
Flask-Mako==0.3
Jinja2==2.7.2
Mako==0.9.1
MarkupSafe==0.18
Werkzeug==0.9.4
itsdangerous==0.23
wsgiref==0.1.2

Users would install the dependencies with

pip install -r requirements.txt

When a new dependency is introduced or an existing one is updated, the developer who introduced the change can run

pip freeze > requirements.txt

and requirements.txt will be updated with the correct required dependencies as well as their versions. Ideally, developers are using a virtual environment for each project, allowing each project's dependencies to be installed without collisions.

Furthermore, this allows other developers who want to install an older version of traffairious to install the versions of the dependencies which were used with that version of traffairious.

Further reading:

@citruspi

P.S. I realize that I could have just pushed the change without opening this issue, but I just wanted to explain the reason for the change for anyone who isn't familiar with packaging in python and with managing dependencies.

@citruspi This is so good!!! @ralphbean, @ryansb, and @oddshocks: you should check this out too.

This, to me, sounds like a patch we need to make within pythong (https://pypi.python.org/pypi/pythong) which is the tool I used to generate the setup.py. It sounds like pythong should be able to create a requirements.txt file, instead of a setup.py file, based on a question such as "Will this project be used as a module within other modules or applications?"

Very awesome work here Mihir. I Will be using this within the AdvProj FOSS course this Semester :)

citruspi++++++++

On Wed, Jan 22, 2014 at 3:25 PM, Remy DeCausemaker <notifications@github.com

wrote:

@citruspi https://github.com/citruspi This is so good!!! @ralphbeanhttps://github.com/ralphbean,
@ryansb https://github.com/ryansb, and @oddshockshttps://github.com/oddshocks:
you should check this out too.

This, to me, sounds like a patch we need to make within pythong (
https://pypi.python.org/pypi/pythong) which is the tool I used to
generate the setup.py. It sounds like pythong should be able to create a
"requirements.txt" instead of a setup.py file,, based on a question such as
"Will this project be used as a module within other modules or
applications?"

Very awesome work here Mihir. I Will be using this within the AdvProj FOSS
course this Semester :)


Reply to this email directly or view it on GitHubhttps://github.com//issues/30#issuecomment-33063787
.

Tim Duffy
http://timduffy.me/
(585)-210-8353
@arbiterofbits

@decause,

Thanks, glad to hear you like it. 👍

@citruspi

It sounds like pythong should be able to create a requirements.txt file, instead of a setup.py file, based on a question such as "Will this project be used as a module within other modules or applications?"

You can also straddle both approaches by adding a function like this one to your setup.py: https://github.com/fedora-infra/datagrepper/blob/develop/setup.py#L31-L33

@decause,

I just installed and ran through pythong, and I'll be honest, I don't think it's worth adding.

Here's what I ran through with pythong:

Project name: temp
Would you like a bin directory? [Y/n] n
Would you like a tests directory? [Y/n] n
Creating structure for new Python project temp.
Would you like help creating a setup.py file? [y/N] y
Encoding [utf8]: 
Version [0.1.0]: 
Short name [temp]: 
Description [A new project]: 
Would you like to select classifiers for your project? [y/N] 
Keywords (comma delimited): 
Author: 
Author email: 
Project URL: 
License: 
Requirements (comma delimited): flask==0.10, jinja2
Configuration file written.
Setup files written.

The requirements was the last part and I had to specify version numbers myself. Everything else (i.e the name, bin, temp, encoding, etc. options) isn't part of a requirements.txt file.

Personally, I think it would be easier to use

pip freeze > requirements.txt

than it would be to manually run through the pythong prompt.

Plus, that way I wouldn't accidentally forget a dependency when manually specifying them.

@citruspi