On Tue, Jan 4, 2011 at 3:05 AM, Diez Roggisch <[email protected]> wrote:
>>The OS dependency management is really not what I'm trying to be
>>illusttrative of here. I'm trying to show that deploying a single rpm of
>>all your dependencies is problematic compared to deploying with an rpm for
>>each of your dependencies. This is not a comparison of system package
>>managers vs virtualenvs.
>
> You claim it is problematic. I see no attempt at proving that. But see below.
>
I've already said that in the first email
"""
A little unrelated, putting all of the eggs you depend on into a single
deb/rpm really is a recipe for disaster as it means that you need to manage
the builds for all of the packages should you need to make changes to just
one.
"""
>>> - manage to install it without provoking a conflict with the system's
>>> version
>>
>>In either case, once Step 5 above is complete, installation is:
>>
>>yum install -y python-sqlalchemy0.6
>>
>>There will be no conflicts because of the way we installed took care to
>>use eggs to install in parallel.
>
> This is the interesting bit. You say they are installed in parallel. How so
> exactly?
As written above, the following two steps:
CFLAGS="$RPM_OPT_FLAGS" %{__python} setup.py--with-cextensions bdist_egg
easy_install -m --prefix %{buildroot}%{_usr} dist/*.egg
That installs the package into the
/usr/lib64/python2.7/site-packages/SQLAlchemy-0.6.5-py2.7.egg-info/
directory and makes it available to the egg mechanism to find.
> And how do I determine which version I get if I do
>
> $ python
>>>> import sqlalchemy
>
Taking that invocation literally, you would get the version installed
by the OS vendor. (In my example, that's SQLAlchemy 0.3) If you add
the code that I mentioned in the previous email, the code that you
write will pick up version 0.6 of sqlalchemy when you do import
sqlalchemy. See the next section for more on that:
> Especially, if I'm going to deploy/develop code for both respective versions?
>
As I wrote before, to get the specific versions that you wish, you
need to get the dependency (indirectly is fine and what I consider
best practice) into __requires__ before you import pkg_resources. For
instance, if you wanted to import the 0.6 version of sqlalchemy in my
example from the python interpreter you could do this:
$ python
>>> __requires__ = ['SQLAlchemy >= 0.6']
>>> import pkg_resources
>>> import sqlalchemy
>>> sqlalchemy.__version__
'0.6.5'
In what I wrote before, I made the requirement for SQLAlchemy >= 0.6
part of the egg metadata for the application (listing it in setup.py)
and then set __requires__ to require the app. This indirectly
references the required version of SQLAlchemy and I consider it a
better practice in general as it means setup.py is the only place you
need to update your versions should things chang e(For instance if
you update your SQLAlchemy requirement or if you require a specific
version of Mako and Pylons as well).
See my previous message for where the places I've found necessary to
set __requires__ for deploying via paster vs deploying via mod_wsgi
are.
> That is the key. If you have an actual working solution for that, I'm all
> fine with using OS packages for deployment, including even the splitting up
> into several packages - because then there is a real benefit to meet other
> apps dependencies.
>
In some cases, virtualenv's do make more sense but in other cases,
using OS packages is the way to go (just as I tried to explain in my
original post). There's a whole set of costs and benefits to each
that need to be applied against the particular environment and
(usually human) resources that are available where you're deploying.
>>With this setup, the original python-sqlalchemy package continues to be
>>under distro control, getting the updates that the distro deems necessary.
>
> The original - sure. Yours not, so all the burden of monitoring bugfixes +
> updates for 0.6, and thus there is no real benefit except from
> IT-requirements of course.
>
Of course. I was going to write something about that but decided not
to because it seemed obvious that you, yourself, always carry this
burden once you decide not to use the vendor supplied package. The
burden of monitoring for security and bugfixes, incompatibility in
potential updates, etc becomes yours to carry whether you're building
a single rpm for the dependent modules, many rpms, or deploying in a
virtualenv. From this point of view, I'd say that using system
packages as much as possible is highly to your benefit (as that means
that you have to watch for changes in the fewest upstreams possible).
Of course, you need to settle on a Linux distribution that maintains
API compatibility when doing updates so that you can thoughtfully
build your requirements on top of it rather than fighting with it when
it upgrades to an incompatible version and you have to scramble to
either deploy an older compatible version or update your code.
-Toshio
--
You received this message because you are subscribed to the Google Groups
"TurboGears" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/turbogears?hl=en.
