Every so often, I see a new package listed on the Python Package Index that claims – in its tag line, no less – that it offers some feature “without external dependencies”.
The authors of such packages must think it’s a truly valuable feature, to list it in the tag line (“description” field of their setup script).
But I’m a little confused by why they’re uploading it to the Cheeseshop. After all, anybody who believes that a lack of dependencies is good… isn’t going to be able to use it! 😉
And anyone who doesn’t care that much about dependencies (perhaps because they use setuptools?) was probably already using whatever package the new package is intended to replace.
Sure, if the package also offers some other features, a better API, or something like that, it gives people more choices, encourages competition and all that other good stuff. And I certainly don’t want to discourage anyone from uploading useful things to PyPI.
I’m just puzzled by the idea of advertising that your package has no external dependencies, when, as far as anybody else is conerned, it is an external dependency. Seems like that space could be better used to promote whatever other benefits the library brings.
Just one of those “things that make you go hmmm” I suppose.
I don’t agree with you. I sometimes want to have library that do X and for sake of distribution/deployment I don’t want any external deps. So I simply take the needed library and put it directly in my code/repo. Generally speaking it’s not about not having external deps (like Python interpreter itself), but to minimize them.
Setuptools is nice if your doing some bigger project, but I’m a student and often write programs as study-tasks and then I’m interested in deployment ease [like: “checkout my initial commit, there’s all you need”]. Moreover I find setuptools a bit to complicated for small, quick&dirty.
A program with complex dependencies is always a problem for distribution. Primarily when thinking about cross platform support.
I will always check out a limited dependency package before competitors needing more. “Reduced dependencies” is always my first choice.
These types of packages are trying to reduce two primary problems.
1. Dependencies on binary packages. These always make life hard for distributing to multiple platforms.
2. Webs of version dependencies that end up creating conflicts. Easy_install tools can assist with multiple versions, but they require planning ahead of time and cannot solve the real problems.
For our grid at work, knowing that a package has no dependencies is a HUGE bonus. We have a massive grid and need to roll out upgrades. Having to manage conflicting dependencies is one of the larger problems.
Knowing that the package does not have any dependencies means that we can roll it out much much faster.
“No external dependencies” means you don’t have to find and compile a c-library, I think. That can be a pain sometimes.
There are some real dangers you get into when your dependencies get too complicated. You get conflicts if different libraries have conflicting dependencies. Things might work out now, but what about in the future? And the error messages you get when there’s conflicting dependencies hardly make the issue clear. The order of installation itself tends to be cause success or failure — if you install the less-restrictive library first things will work out, if not you get some weird installation conflict. Multi-version installs only defer the conflict.
And there’s still no real solution to keeping your dependencies in-tact. There’s some ad hoc solutions — extras that define recommended packages, or some tools like repoze’s and poach-eggs to pin the versions. But without those the (validly!) vague version declarations in packages can fall apart as packages upgrade and introduce new and unexpected conflicts.
One level of dependencies is manageable (though not without its problems), but we don’t have the tools to handle deeper dependency graphs. Or, more generally, the community knowledge about good practices in deployment.
This is simple.
Easy is beautiful.
Short is beautiful.
And the more you require, the more dependant you end up.
this may sometimes have advantages, but often it just leads to problems. I can thus understand people who dont like to include a lot of deps if it is avoidable
Just want to add +1 to what Ian Bicking mentioned in his comment. Having a dependency tree that is one level deep instead of 2+ levels deep results in less effort to modify things.
With the project I work on, 4Suite-XML has probably cost us close to 6 months of developer time because of continued issues with its dependency on certain versions of expat, combined with the lack of time to fix the problem correctly. Now when I evaluate a library, fewer dependencies means that I will be able to upgrade my programming environment more easily and quickly.
it’s ironic that in your description for the simplegeneric package in PyPI you say “it has absolutely no dependencies” as if it was a positive thing
I just wanted to point out that at least one person, Robert Martin, has thought deeply about this issue as part of a set of OOD tenants that have been coined SOLID principles.
The one that’s relevant to this discussion is the Stable Dependencies Principle (SDP). Basically, the assertion is that one should depend on packages that are at least more stable than one’s own. Martin then presents a simple metric to determine “stability” that punishes a package for its external dependencies relative to how many packages are dependent on it. Martin really doesn’t present the metric as much more than a guideline or rather a way of succinctly describing his principle.
Martin is somewhat a celebrated figure in the OOD community. Personally, I don’t find much of his principles that controversial. Furthermore, he does a good job making his case for them. His discussion of SDP is pretty much in line with some of the comments above.
I want to note, though, that I think there’s a bit of zealotry behind Martin’s principles. When I first encountered people talking about “SOLID principles,” it sounded like a bunch of hype. I was a bit disappointed when the principles turned out to be straight-forward things I’d been doing anyway. On the other hand, it’s good that someone wrote them down and gave them some names.