Manage django, cloudfiles and boto as external dependencies

[benoitbryon]

Django, cloudfiles and boto are external libraries. They should be installed and imported as external dependencies, i.e. not included within fileconveyor's source code.

Django-storages is a special case, see #6.

Currently fileconveyor uses the following versions:

• Django-1.0.2. May be updated to 1.0.4. Latest version is 1.3.
• Python-cloudfiles-1.4.0. Not available on Pypi. Latest version is 1.7.9.1
• boto-1.6b. Latest version is 2.0.

[benoitbryon]

Created dependencies-external branch to resolve this issue. Tests with nose (see #83) pass on that branch (they currently don't on "packaging-egg" branch).

Documentation has not been updated yet. Notice that when you install fileconveyor with easy_install, pip or buildout, you automatically get the dependencies.

The "dependencies-external" is based on #81 pull request. So I'm to wait for #81 to be closed before I do a pull request.

[wimleers]

A problem is that I don't need all of Django. I only need a tiny subset. How would you handle this?

(Note that the original reason for including them in the sourcecode is to prevent problems due to people using different versions of said external dependencies. Now it of course makes little sense.)

[wimleers]

81 will be fixed as soon as you've addressed the problems that I encountered (see the comment I just posted). Then you'll be able to continue with this!

[benoitbryon]

Django is monolithic by design (Django fans say it is consistent). The drawback is that you cannot download only parts of it. You download it all or nothing.

In this particular case, my advice would be to download it all, even if we don't need all Django:

• Your installer (pip, easy_install, buildout or whatever) would download/install it for you. You don't have to worry about it.
• If you duplicate parts of the code, you have to maintain it. I guess that is neither easy nor efficient.
• If you install Django as a dependency, yes you don't use it all, but you don't have to care about the parts you are actually using. They work. They are maintained. It's enough.

The question "why is Django monolithic (or consistent)" sounds like a troll in the Python community... To this day, Django developers chose the "monolithic" way... Personally, I don't like this design. I agree with Gawel on most points. ... so we could argue but the facts are: Django is monolithic, download it all or don't use it.

IMHO, the true question here is: do you want to maintain Django parts?

[wimleers]

No, we don't want to maintain Django parts. That's just plain silly.

I wasn't aware about this specific design decision of Django — I just searched for something like "storage systems abstraction for Django" and stumbled upon django-storages and then ripped out the parts of Django that I needed. yes, that was hacky. Yes, that's evil. Yes, that's what I had to do to finish this very large bachelor thesis on time. Yes, now is the time to fix that :)

I just read Gawel's post and it seems it's monolithic for the same reason I hacked all this code into File Conveyor:

Yes Django is monolithic and this is one of the great things about it. One package instead of a bunch of dependencies to keep track of.

:)

Conclusion: consider my question answered and void, and please continue along this path :)
However, the fact is that File Conveyor will become much harder to install. Instead of a single git checkout/tarball unzip, you now have to run various commands. The upside that more than compensates this downside is the simplified development and maintenance :)

[benoitbryon]

You only need one command if you use a standard installer, such as easy_install (which can't uninstall) or pip. You neither have to wonder how to install dependencies nor read a long documentation, because installers do the job.

[wimleers]

87 closed, which also closes this issue.