Re: [Paste] paster --create : can I make a package that is n…

Top Page
Author: Ian Bicking
To: Matt Feifarek, pylons-discuss
CC: paste-users
Subject: Re: [Paste] paster --create : can I make a package that is not an egg?
Matt Feifarek wrote:
> Hi Pasters.
> I appreciate all of the attention and time put into getting me into Good
> Habits w/r/t eggs and unit testing and i18n and all of that... it seems
> very well thought out and very complete... thank you Ian.
> However, most of my projects right now are Pylons applications for a
> specific purpose (usually some dumb boring business-y thing) that will
> *certainly* never go in the Cheese Shop or be distributed via setuptools
> or anything like that. So, for me, eggs are overkill... they're a
> solution without a problem. I'm okay with plain old python packages. I
> dare say that this might apply to lots of folks.

Well, this is generally about how the Pylons template is set up -- Paste
Script will create files however you want. But then Pylons is following
conventions that Paste Script (and myself) prefer.

> There are many files and metafiles that I don't understand in my
> project, and that makes me nervous. Also, the 'shelled' nature of eggs
> bugs me: the app isn't in the app directory, it's INSIDE of the app
> directory. For a stand-alone project like a library or some such, it
> makes excellent sense. For an app that contains some web code, some
> logic, some resource files, some data... it mucks things up a bit.

These extra files are about presenting an API to the world that is
fairly abstract -- mostly the Paste Deploy API. This hides Pylons, and
even Paste, and makes it easier to deal with your application in an
abstract manner.

> I know about the smaller version of the Pylons template, but I do need
> some of what comes in the big template.

The smaller version is nested similarly, so it doesn't really change
anything you are describing here.

> Here's what I would like to do; perhaps there is a command line switch
> to paster (I couldn't find it in the docs online). I'd like my
> application to be structured something like this:
> myapp/
> myapp/
> myapp/some_arbitrary_package_code/
> (etc)

This is conflating the directory you put something into with the Python
package. It makes things like branches awkward, and you can't build on
tools like workingenv.

> then:
> myapp/wwwapp/ <---- this and everything below it is a pylons app,
> created by paster create
> myapp/development.ini (for serving)
> myapp/deploy.ini

Personally I don't think deploy.ini should go in the main package at
all, though I can understand why people wouldn't want to introduce the
extra abstraction when they are doing only simple deployments.

> Is this possible? Or, maybe, can someone talk me out of wanting to do
> this? ;-)

Well, I'll try to talk you out of it:

* The overhead isn't that much, it's just one extra directory.
* You can name the most-parent directory whatever you want, e.g., put
the tag or branch name in it.
* You can formally declare what your dependencies are in You
can switch those up in different versions, etc.
* While initially versions and tags and branches might seem unnecessary,
they always are in the beginning, and aren't later on. To manage all
this, you need some kind of metadata -- and eggs are a
reasonable set of metadata that we can agree on.
* There are tools that can use that metadata. Your application may not
end up being the most front-facing application -- e.g., you might want
to do dispatching with urlmap to run multiple applications, or you might
be using supporting tools, or you might wrap multiple applications in a
single authentication middleware. If someone else wrote one of those
pieces you'll need to set up your application in a way that those
foreign pieces can access it. That's the way Pylons is set up by
default, so you are all set (without even knowing it ;).
* Some of the other stuff in Pylons specifically (config, environment,
etc) support customizations you might want in the future, but don't yet.
  That's really a separate issue, but there's reasons for each one of them.

Ian Bicking | ianb@??? |

Paste-users mailing list