Disqus - Latest Comments for jacobian

Re: Being A Manager Is Lonely

jacobian — Wed, 14 Jan 2015 14:30:47 -0000

Great post, Ian; this is something I really struggle with, as well. The concept that as manager you're personally responsible for *all* the companies decisions -- ones you advocated against -- is tough, tough, tough. But it's important; organizational aligning is critical to a company's success, and we all want to work for successful companies (right?)

One thing that strikes me reading this, though, is that if you're feeling lonely about this you may not have the professional support you need in your role. You write that you "... cannot discuss [your] job. [You] cannot debate the details. [You] cannot tell anecdotes to elucidate a point. [You] cannot discuss the policies [you are] asked to implement".

If this is true -- and I hope for your sake it's overstated -- then something's not right. These are things that you should (and must!) discuss. You should be able to discuss these things with your manager, with your peer managers in the same group, with your mentor/coach, etc. It's terrifically hard to work through these issues without support.

Re: Djangorecipe updated for the upcoming buildout 2.0¶

jacobian — Fri, 25 Jan 2013 10:06:38 -0000

FWIW, we can't put pre-release versions of Django on PyPI because of problems with PyPI/distutils; it's really not an isolated island sort of thing.

PyPI and the various installers are rather dumb about what they considers a "release": when you say (e.g.) "pip install django", you get whatever the "greatest" version number is. So if we put, say, 1.5 alpha on PyPI, anyone who did "pip install django" would get the unstable alpha instead of the stable 1.4 they expected (because "1.5a1" > "1.4"). This is pretty unfriendly to users: I think most people expect to get stable, release-worthy software from PyPI, so giving them unstable pre-releases is a nasty surprise.

(This isn't academic, BTW, we found out about this the hard way when we put 1.2 alpha on PyPI and almost immediately started getting *tons* of confused users on #django and in other support channels.)

If I'm missing something that'd let us list pre-releases on PyPI without triggering this problem PLEASE let me know! I'd love to find a workaround.

Re: Dear Django, help Python Packaging

jacobian — Mon, 10 Sep 2012 13:00:39 -0000

I don't think anyone's suggesting Django use setuptools; I'm afraid this is all a misunderstanding, and it's probably my fault. I'll try to fill in the missing pieces, perhaps this'll help put what's going on in context.

At DjangoCon, Chris McDonough gave a great talk called "About Django from A Pyramid Guy": http://plope.com/static/pre.... Around slide 19 he talks about the fact that Django stopped using setuptools in 2008 (ish) and hasn't gone back. (Our setup.py just uses vanilla distutils.) There are a ton of reasons why this is a problem, from small issues like "setup.py develop" not working, to bigger issues like our need to vendor things (unittest2, simplejson, etc.), to super-big issues like our community's general lack involvement with the packaging discussion [*].

After the talk, as usually happens, a group of us stood around and talked for a while. I said that I strongly agree with Chris: our "opting out" of modern packaging tools is starting to hold us back. For example, I really want to use mock in our test suite, but I haven't proposed it because vendoring yet another thing makes me sad. Or, further down the road, I'd actually like to start breaking some parts of Django out into separate packages; this basically isn't possible without proper dependency management.

So what I *said* is something along the lines of "we should switch back to setuptools" and I think that's what's got this whole silly rumor-mill started. But what I *MEANT* was that we generally need to upgrade our packaging-fu. There's been a ton of movement in this area over the last year, and I honeslty haven't been able to keep up. I *think* the state of the art is now "packaging", but that's only Python 3 (right?), and so on Python 2 it's "distribute"? Either way, saying "setuptools/distribute/packaging" is a big mouthful, and so I think I used "setuptools" as a sort of shorthand for "... something better ...".

I'm not in any way suggesting we ignore recent developments. My problem is just that I find these recent developments somewhat confusing, and I don't know what the plans are, what those timelines look like, and how Django can best leverage this work.

Django needs better packaging tools, and we'd love to help out. Tell us how. PEP-345 metadata sounds like a good first step; is there some good documentation on how to add that to our package? We've got a few months before Django 1.5 ships, it should be very easy to get at least that first step done by then.

[*] That is, while a few awesome people - jezdez, carljm - are both involved in Django *and* very involved in the evolution of packaging tools, for the most part our respective communities don't overlap.

Re: Infrastructure for Modern Web Sites

jacobian — Sat, 31 Jan 2009 19:12:33 -0000

Yeah, the more I mull it over the more a "framework distribution" seems like a good idea. Maybe I'll even make some time to work on one.

You're right on, though, that "NG web frameworks should aim to allow those to be coupled easily, and probably to provide some additional management functionality." Take Django's admin being hostile to -- er, more like almost completely incompatible with -- third-party ORMs: we're in 100% agreement that this is more like a "bug" than a "feature." It's actually one of my top priorities, along with about three hundred other things. (I think I need a better way of categorizing my todo list.)

A framework with hooks for "the rest of the stack" is a better framework. It won't happen overnight, but my hope is that over the next few releases we'll be able to shape Django along these lines. Sharding/federating/slaves is a pretty good example, actually: Django 1.0 has all the low-level plumbing needed to support multiple databases. All the hooks are there, so what's needed is a bit of a higher-level API for convenience and some documentation explaining how to handle common patterns. We have to do the plumbing first, though; that way the early adoptors can help us figure out what style of porcelain to build.

I'm hoping we'll be able to follow this pattern in other areas -- introduce the low-level hooks, let folks fool with 'em, and then make the common patterns easy and documented. For example, my current bugaboo is monitoring: Django's pretty opaque about what's going on internally. I'd like to make that data available to external monitoring tools (Munin, Cacti, Zenoss, ...) but what I really DON'T want is to build a full-stack monitoring tool into Django itself.

Re: Infrastructure for Modern Web Sites

jacobian — Sat, 31 Jan 2009 17:57:03 -0000

Thanks for the list, Leonard -- it'll make a good reference the next time I need to explain why writing a quick application is really just the *start* of a web developer's job these days. Like Ned I've cobbled together most of this stuff myself. Indeed; I've hacked together some of those "below the line" components at least three times.

For me, though, the really interesting part is that it seems you're arguing that these parts ought to be part of a modern web framework. And you might think I'd agree given the amount of time I spend on this stuff... but I'm not sure I *do* agree.

See, I tend to think of this stuff as "the rest of the stack" for a good reason: it all tends to be *very* domain-specific. "Sharding" is an easy shorthand for a common feature, but I suspect if you inventoried a bunch of large web apps you'd find each has a substantially different interpretation of what a "shard" actually is. Case in point: I've designed or implemented four different somethings I'd call "sharding" on a resume, but really the similarity stops at the umbrella term. I think it'd take more time to route around an almost-certainly-useless set of defaults than just to start from scratch each time.

I think the problem is that when you start to write down the commonalities in these "below the line" bits of different apps you come up with a *really* small overlap. For me this is most striking when it comes to deployment: having tried a bunch of different deployment "frameworks" I'm starting to realize that the only common feature set I need is ssh and a for loop. Anything else I inevitably just have to route around or rewrite eventually anyway.

It seems trying to implement the "below the line" features in a common way would just be an exercise in frustration.

I think what might be needed here is some sort of "framework distribution" -- Django/Rails/whatever plus all the "other stuff" you'd use in the Real World. Like the "GNU" in "GNU/Linux". After all, all these "below the line" tools already exist in various and sundry forms, it's just that (in grand open source tradition) they're not integrated. A determined party could pick a best-of-breed from each category, write a bunch of wrappers, configuration, "glue", and GUIs and ship a distribution (or launch it all as a hosted platform). I think it's only a matter of time, really.

Re: Is this a canonical Python HTTP POST with Basic Authentication? - RussellBeattie.com

jacobian — Tue, 02 Sep 2008 19:43:08 -0000

There actually is pretty extensive documentation: http://bitworking.org/proje.... It's also basically a single-method library, so it's very easy to get started with.

Here's what post-to-twitter looks like with httplib2: http://dpaste.com/hold/75561/

If you ask me, the fact that this isn't part of the stdlib is simply criminal.

Re: DjangoCon 2008 iCal Schedule - Officially Lucky, a blog by Clint Ecker

jacobian — Tue, 26 Aug 2008 21:55:37 -0000

BTW, keep an eye on the schedule page; we'll need to tweak things a bit in the next couple of days.