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/__init__.py > myapp/some_arbitrary_package_code/__init__.py > (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 setup.py. 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 -- setup.py 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 | [EMAIL PROTECTED] | http://blog.ianbicking.org _______________________________________________ Paste-users mailing list [email protected] http://webwareforpython.org/cgi-bin/mailman/listinfo/paste-users
