cc @lsix

#19989

Packages shouldn't depend on a specific version by directly referring to the attribute. What I mean is, its not good to have django_1_6 as a buildInput. Instead, use the approach as is done by lti, i.e., override self.

let 
  self' = (self.override {self = self';}) // {django = django_1_6;};
in .....

 propagatedBuildInputs = with self' [ django ... ];

Perfectly, it works: it has the same behaviour for python35, python34 and python33. Yes, it is better to override self instead of each package.

even so, I am not so fond of having this. What you easily get now is that you include this package, and then another package that also depends on django, and suddenly you have two versions of django in your closure...oops!

Instead, the user should override the package set and select the correct Django.

@FRidh, I've updated MR. Is it ready to be merged?

While I am not fond of this solution, it is okay. But, before I merge, is there any reason not to update mezzanine to the latest available version?

Because, unless some other Nixpkgs package needs it, we do not keep older versions.

Yes, it makes sense. But I need to update filebrowser_safe, grappelli_safe and add django-contrib-comments package. Can I do it in this MR or split them?

do you need all packages, including this mezzanine, at the latest version, or not? If not I suggest you use pypi2nix

No, I personaly don't need the latest version of mezzanine. I just want the mezzanine to be compiled because I can't move forward with pyjwt and oathlib packages that are required for conan.

ohh, ok. Since the mezzanine version we have is so old and because it is not worked you can add meta.broken = true;. Leave it to a user of mezzanine to fix it.

Seems fair to me to mark it as broken until someone proceed with the updates.