-
Notifications
You must be signed in to change notification settings - Fork 7
Home
Over the last decade and a half, we have designed, implemented, maintained, and operated a large number of complex systems with very few programmers. Our opinions have helped in a number of ways. The most important one is that we didn't have to think much about how to build applications: policies were defined, and we followed them. If policies needed changing, they were changed, and we all followed the new ones.
We are very opinionated about code, tests, frameworks, and methodology. We are automation obsessed (kudos for the term to Mitchell Hashimoto), which is what all the opinions are about.
Being opinionated adds significant value: more reliability and faster
coding. You don't have to guess what to do, because there's probably
an opinion about it. Mitchell Hashimoto wrote Vagrant in
Ruby, which means that Vagrantfiles (config) are written in Ruby. There's a single
command vagrant, which invokes all sub-commands. Couldn't be simpler, or more
BOP-like.
Python is opinionated about some things, but mostly, Python follows Perl's adage that there is more than one way to do it. This creates chaos. Consider the simple problem of configuration, which is required by all systems. When you search on config on PyPI (not to be confused with PyPy), you get a list of hundreds of modules, many of which are some type of generalized configuration support module. Search for template, mail, etc.
Our experience with Perl has taught us that you have to be wary of CPAN modules. They often work for basic things, but fail to solve the problems in general. Authors generally are happy with bug fixes, but aren't so happy with opinionated contributions. So, we ended up wrapping many of the CPAN modules as we built our first SaaS site in Perl, way back in 1999.
In a nutshell, we know we are going to need to enhace and to replace Python modules. That's why we need PyKern.
Java got naming right. The naming chaos in PyPI and CPAN creates unnecessary naming difficulties. There were naming conflicts with BOP modules and anything in CPAN.
PyKern (or pykern) is a globally unique name (we own various domains). We don't have to worry about naming conflicts with any other modules if all our modules begin with pykern.
BOP is a single package with over 1000 classes. That may seem problematic to some people, but it simplifies deployment. There are no version mismatches. All the modules in the distribution pass all the tests.
It's common practice to install large numbers of packages with a base installation of a programming language. The basic Python installion comes with over 400 modules. Perl is similar with over 500 modules. If you install Anaconda the Python distro from Continuum, you get over 13K modules. PyKern is in good company.
You also don't need to worry about something not being there. There are no dependencies to update. As you add modules, they just become visible.
The following wiki pages discuss our thinking on various modules in PyKern: