Re: A Python Web Application Package and Format

On 2011-04-18 16:36:28 -0700, Daniel Holth said:
> On Apr 18, 2011, at 6:09 PM, Alice Bevan–McGregor wrote:
>> I've already defined that.  RTFM or many ML messages about logging.
> 
> Please remain friendly and patient. 

That depends on how you define the F in RTFM.  In this instance, I 
meant "read the fine manual".  ;)

You can understand my frustration, however, that > 10% of the posts in 
this thread demonstrate a lack of understanding of (or lack of even a 
cursory glance at) a) my initial post and associated document, and b) 
the rest of the mailing list posts.

Asking for things already agreed upon or questions already resolved 
wastes everyone's time.

On 2011-04-18 16:46:12 -0700, Eric Larson said:
> Instead of assuming "/etc" always means "the root of the filesystem" we 
> should consider it the "root of the sandbox" where the system providing 
> the "sandbox" defines what that is.

While /etc certainly wouldn't be the root of anything (insert sarcastic 
smiley here ;), it was already agreed upon that / would refer to the 
application container root, not system root.  I share Ian's sentiment, 
see: (search for 'root' on that page)

http://mail.python.org/pipermail/web-sig/2011-April/005041.html

> It is _a_ filesystem in that there is a place that an application will 
> be run. For argument's sake, we'll say it is a directory on some 
> server. Now, within that directory we choose to take some known bits 
> from the LFS standard such as /etc, /bin, /var, etc for the placement 
> of our application.

Again, not such a great idea.

> With that in mind, I think using things like LFS makes a ton of sense. 
> We can piggy back or copy (since previous discussions for .debs or rpms 
> seem not to sit well... even though they would fit this model very 
> well...) systems like RPM rather directly and hopefully allow our 
> Python web apps to play very nicely with applications in other 
> languages.

I can't fully grok this paragraph.  FHS (my bad calling it LFS 
earlier!) = good because we won't confuse systems administrators and it 
matches other binary packaging models?

I doubt an isolated web application will have a need for more than 6% 
(3) of these:

http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard#Directory_structure

While I personally have a FHS-like application deployment model using 
Git, I would rather not see that level of complexity as a requirement 
for deploying basic applications.

> Please do not get hung up on the fact that I've said RPMs here. The 
> fact is distros have been doing package management for quite a long 
> while. It is insanely convenient to say apt-get install couchdb and 
> when it is done, having a couchdb server running.

It may be convienent, but it's also quite the risk.  You're letting 
someone else configure your server.  Also, do binary installation 
systems automatically start the service post-installation before you 
can configure them?  I have difficulty believing that, which means a 
whole whack-ton of effort under a systems administrator hat has been 
glossed over.

> Copying the model seems like a good option in that we get to learn from 
> the mistakes of others while inheriting a wild variety of tools and 
> concepts.

The on-disk structure which the application lives within (the 
"application container") is up to the application server in use.  The 
underlying application should, and, IMHO, -must- be agnostic to it.  
Passing paths to configuration files, TMPDIR, etc. in the environment 
is a fairly trivial way to do that, at which point the FHS discussion 
is nearly moot.

If you want a complete (complete enough for a simple web application) 
FHS structure within the redistributable, I don't see the point of 
having that many empty directories.  ;)

As an aside, I -do- have an application in production using a FHS-like 
file structure:

	https://gist.github.com/926617

But again, I'm not suggesting something like that for the 
redistributable application!

	— Alice.


_______________________________________________
Web-SIG mailing list
[email protected]
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/gcpw-web-sig%40m.gmane.org