[repoman] platform thoughts

[Essien Ita Essien]

Paul Mattal wrote:
> Just in case the deep repository thinking doesn't generate any traffic, 
> I figured I'd throw in something more practical and likely to generate 
> replies, and also that will be immediately useful in getting things going:

FWIW, here are my thoughts.
> 
> 1) I've started working in python for repoman. I think it's very 
> flexible and likely to be a good choice for the project. Anyone want to 
> lobby for another language before we settle on python?

Python +1 :)
If we wanted something else, I'd say D or C, but it seems that most of 
the devs have pretty decent Python experience.

> 
> 2) I am settling on sqlite as squarely between a big RDBS like mysql and 
> postgresql (which I'd like to avoid) and a text file (which may be 
> underpowered for our purposes). What do people think about sqlite?

I've programmed against Sqlite and MySQL pretty regularly and I'm okay 
with either one, though benchmarks seem to show that SQLite is faster 
than (untuned?) MySQL for a lot of common operations. Not sure about 
MySQL Embedded comparisons though (last time i programmed against this, 
had a pretty weird C api :) ).

I'd just say... sqlite.

> 
> 3) I would like to use a simple ORM to do *most* things. It's just less 
> code to get wrong. Obviously, we could still write pure SQL against the 
> db at any time. What do people recommend for a python ORM that supports 
> sqlite? SQLObject is around, the django db api is another option (easy 
> addition of web interfaces later), and there's also SQLAlchemy, I think, 
> and maybe one or two others. Thoughts?

I've had bad experiences with SQLObject :(

I use it for a lot of not so complex projects with pretty limited data 
relationships. Once I begin to need to do some serious normalizations, 
JOINs, and other stuff that I could do at the database level, SQLObject 
actually begins to hinder me.

There are also other funny behaviourisms that depend on how you name 
your tables. And did I mention that writing complex JOINs in SQLObject 
just blows?

I've almost personally sworn off ORMs for medium to huge projects, till 
i had to write a small library to allow me work with SQL and still 
benefit from Python representation of objects.

I seem to hear that SQLAlchemy doesn't suffer from all the problems I've 
encountered with SQLObject, and i've never touched Django's ORM b4. If I 
have sometime on my hands this week, I'll play around with SQLAlchemy 
(though its obviously not going to be as good an opinion as someone 
who's used it for more than 4 to 5 serious real life projects)
> 
> - P

Essien
> 
> _______________________________________________
> repoman mailing list
> repoman at archlinux.org
> http://archlinux.org/mailman/listinfo/repoman
>