ImageKit 3.0 Alpha!

[matthewwithanm]

Hello to our tiny group! IK3 is finally ready for an alpha release and I wanted

to give you an overview of all of the new and exciting stuff. I'm going to try

not to duplicate information that's in (or should be in) the docs, but rather

direct your attention towards some of the new features and discuss the thinking

behind them.

I hope that you can all help track down bugs or shortcomings and maybe even help

with some fixes—including beefing up sparse areas in the docs!

New Stuff

3.0 is a feature-heavy release. It also (I hope) fixes several design mistakes

that were made with earlier versions. As such, its development has been

completely driven by the feedback received via GitHub issues; it's been

invaluable.

In broad terms, though, there have been two goals of IK3:

Make It Easier To Generate Images In Non-model Contexts

IK has always been model-centric. But why? Processors have been completely

decoupled from the ORM since 1.0. With this release, we finally deliver on the

promise of that decoupling: template tags! form fields! We gots em.

One often-asked question has been how to use IK to process images in views; with

this version, we finally provide a sensible interface for doing this

without having to dig into the internals of IK or re-implement any of its parts.

Give Users More Control Over Image Generation

2.0's image cache backends were an attempt to give people control over how their

cached images were generated. Unfortunately, I think it missed the mark a bit.

3.0 retains image cache backends (now called cache file backends), but dials

back their responsibility considerably and supplements them with

cache file strategies. These new strategy objects are basically

collections of event handlers that let you specify what needs to happen when,

allowing us to get rid of the hacky `NonValidatingCacheBackend`. In addition,

the bundled cache file backends have been given a nice boost: they now cache

the state of generated images using Django's cache backends. Needless to say,

this comes in handy with remote storage backends.

So Long, Weirdos

In addition to these things, we also strove to fix some of the weird,

unexpected, or inconsistent behavior. For example, if you make a change to a

processor for one of your fields, you no longer have to manually invalidate it

to regenerate the image. That means that the management command for generating

images (which was previously named `ikcachevalidate` and is now called

`generateimages`) will ensure that the correctly processed images exist. Period.

Another example is the creation of specs based on properties of your model

instance. In older versions, this could be done py passing a `cache_to` callable

to your `ImageSpecField` (for customizing the cache files name) or, more

interestingly, by passing it a callable `processors` argument.

Frankly, I was never happy with this behavior. Some of the reasons why are a

little involved but, for one, it irked me that only some of the spec could be

generated based on the model. (What's so special about processors? Why can't the

format be dynamic?) However, (like I noted) the perfect is the enemy of the

good, so we adopted it. Thankfully, with IK3 we gave ourselves the time to

*really* solve this problem. Now the entire spec can be generated based on

properties of the source.

In Conclusion

Hopefully I haven't blabbed too much and you're still awake and ready to dig

into IK3. Eric (@lettertwo) and I have spent a lot of time on it over the

past few months and are really proud of what's come out of it. It's hard to

overemphasize how much better we think IK3 is than version 2. Not only does it

address real problems that people had with the library and sport a ton of new

of new features I haven't even mentioned but, more than that, it's a far more

elegant design. That means that you can do a lot more with it, and that we can

build a lot more on top of it.

We'd really appreciate your feedback on this (alpha) release—bugs, suggestions,

and especially pull requests! Also, this is an alpha so if there's something in

the API you don't like, now's the time to bring it up (but please don't be

offended if we don't agree—we've spent a *TON* of time thinking about the IK3

API and it's not unlikely that we already considered your idea).

Bryan has made the alpha docs available here: https://django-imagekit.readthedocs.org/en/devel-0/

Since this is an alpha release, we're not uploading it to PyPI; you'll have to install

from GitHub:

pip install -e git...@github.com:jdriscoll/django-imagekit.git#egg=django-imagekit

Thanks for the help everybody!

[matthewwithanm]

Just pushed 3.0a3 to the develop branch on GitHub. It should address #185 (reported by @seanbell), which was a regression of #126.

[Graeme]

pip install -e git...@github.com:jdriscoll/django-imagekit.git#egg=django-imagekit

does not seem to work. I get:

Command /usr/bin/git clone -q http://github.com:jdriscoll/django-imagekit.git /home/graeme/webwork/allgalle/env/src/django-imagekit failed with error code 128 in None

using Imagekit 2 for now (which does everything this particular project needs) but it would be nice to try 3.

[matthewwithanm]

We'd like you to try 3!

I ran the same command you did just now and everything was successful. Based on (an admittedly brief amount of) Googling, it seems like other people have gotten this error because of a GitHub timeout. Is it possible that this might have been the case for you?

If not, can you provide the full pip output, as well as the versions of git and pip you're using?

Thanks!