Simplify the setup of Morepath applications

[henri-hulski]

Now we use clean Python environment, in which we install buildout. I think for somebody, who is not a Python freak, but comes for example from the react community this setup could look a little complicated.

For example the instruction for setup morepath_cerebral_todomvc looks like:

If you don't have virtualenv install it::

  $ pip install virtualenv

Create a clean Python environment with virtualenv and activate it::

  $ virtualenv venv
  $ source venv/bin/activate

Setup buildout::

  $ python bootstrap.py

After this you can install dependencies using::

  $ bin/buildout

Once that is done you can start the server::

  $ bin/start

And the first step is actually wrong. It should be something like:

$ sudo apt-get install virtualenv

on a Debian based Linux distribution but for other systems it looks other.

First I had the idea switching to a more pip orientated setup like Flask and Django have it, but on the other hand buildout is really powerful and not that difficult to learn.

The question is, if buildout really needs to run in an separated Python environment as it actually creates its own clean environment. The only thing, which is used from the global environment is python itself. Is this really a problem? Without creating the initial clean Python environment the setup looks much easier and the same for all systems.

The idea is to attract people which are not so familiar with python and make the setup process as simple as possible.

[henri-hulski]

The second thing is, that it's not really clear, where the dependencies are declared. The declaration is actually in setup.py but the versions are specified in buildout.cfg. If there are version specifications in buildout.cfg for packages wich are not declared directly or through dependencies in setup.py they won't be installed. This is a little confusing and difficult to explain.

[henri-hulski]

The last issue is much better resolved by pip with it's requirements.txt.

[henri-hulski]

As an example, what I mean by the confusion I will use morepath_reactredux. In setup.py you have:

    install_requires=[
        'setuptools',
        'morepath',
        'webtest',
        'pytest'
    ],

and in buildout.cfg you have:

[versions]
WebOb = 1.5.1
reg = 0.9.2
venusifork = 2.0a2
morepath = 0.11.1
repoze.lru = 0.6
more.chameleon = 0.1
chameleon = 2.24
WebTest = 2.0.20
beautifulsoup4 = 4.4.1
waitress = 0.8.10
six = 1.10.0
pytest = 2.8.2
py = 1.4.30

When I'm not wrong e.g. chameleon and more.chameleon will not be installed.

[faassen]

For applications I thought the cookiecutter template already uses pip, and http://morepath.readthedocs.org/en/latest/organizing_your_project.html makes no particular pronouncement for it.

For developing Morepath itself I'm sticking to buildout for now.

[faassen]

So I'm +1 on making it approachable for the average Python programmer for applications and using just a virtualenv.

[henri-hulski]

The question is, if buildout really needs to run in an separated Python environment as it actually creates its own clean environment. The only thing, which is used from the global environment is python itself. Is this really a problem? Without creating the initial clean Python environment the setup looks much easier and the same for all systems.

@faassen Any comment on this?

[faassen]

It probably isn't a problem with Morepath today. But if Morepath or any of its dependencies ever make it into a Linux distribution somehow, it will be a problem as buildout doesn't isolate from the system packages.

[henri-hulski]

You are right, the cookiecutter template already uses pip. I just refactored morepath_cerebral_todomvc according to it and everything works fine. I think like this it's easier to understand the setup.

[taschini]

By the way, might this be of interest?

Donald Stufft: “setup.py vs requirements.txt”

[faassen]

@taschini, that would be helpful if we developed Morepath and its dependencies using pip. But we already use buildout for this, along with mr.developer which can solve all of this quite well already ([versions] and `[sources] inbuildout.cfg``).

For example code we should probably go to make them work with released versions of Morepath. They don't always do this now, because historically I wanted to test them with development versions, but that's less important these days.

[faassen]

But that does imply that we should adjust the example codebases we maintain to use pip and published versions of Morepath (and update their readme install instructions). Though I'll personally have to retrain myself to use pip instead of buildout.

[taschini]

What I meant is that the article that I linked might be of interest in understanding the difference in purpose between setup.py and buildout.cfg, which might be seen as analogous to the difference between setup.py and requirements.txt. That might help @henri-hulski with one of his questions.

[henri-hulski]

The conclusion of this article is to use

-e https://github.com/foo/bar.git#egg=bar
-e .

inside requirements.txt.

I think this is the same what the cookiecutter template does on command line:

$ env/bin/pip install -e . 

[faassen]

(note: I'm not an expert on pip)

The article talks about developing a core with dependencies that are developed the same time, which is more a concern for Morepath than it is for applications that use Morepath. Applications that use Morepath would use a released version of Morepath and its dependencies.

But Morepath does develop its core along with Dectate and Reg, so it's more relevant there. But we use equivalent strategies in buildout.cfg

[faassen]

I think we should follow the cookiecutter example for all Morepath sample applications we have in the morepath organization. Since I think @henri-hulski's original question has been answered, I'll close this issue and create a more concrete issue about that.