#pinax-dev
March 9th, 2010
| 21:48 | PinaxTracker | pinax: project_improvements Brian Rosner * 760038d (2 files in 2 dirs): Changed version strings to follow the guidelines outlined in PEP 386 |
| 21:48 | PinaxTracker | pinax: project_improvements Brian Rosner * fae5010 (1 files in 1 dirs): Support development versions using an environment variable |
| 21:48 | PinaxTracker | pinax: project_improvements James Tauber * f2e03fd (1 files in 1 dirs): updated description of Pinax in README |
| 21:48 | PinaxTracker | pinax: project_improvements Brian Rosner * 35fe84a (2 files in 2 dirs): Merge branch 'pep386version' |
| 21:48 | PinaxTracker | pinax: project_improvements Brian Rosner * 6849713 (1 files in 1 dirs): Corrected a trailing whitespace |
| 21:48 | PinaxTracker | pinax: project_improvements Brian Rosner * e099437 (4 files in 4 dirs): Merge branch 'master' into project_improvements |
| 21:48 | PinaxTracker | pinax: project_improvements commits 724d7e3...e099437 - http://bit.ly/cxxAQB |
| 21:48 | brosner | it really doesn't have to show each commit in the merge. retarded. |
| 21:49 | brosner | PinaxTracker is just pulling a lukeman |
| 21:49 | lukeman | i was thinking the same thing |
March 10th, 2010
| 00:24 | brosner | jezdez: ping |
| 00:24 | jezdez | pong |
| 00:24 | brosner | i just realized that my os.environ trick for dev number in version won't install with that. i am wondering what bad side-affects that might have? |
| 00:25 | brosner | in my experience when two versions install as the same version using -U always handles it correctly because of uninstall |
| 00:29 | jezdez | yah, it should, it all depends on the pkg_resources version cmp stuff |
| 00:30 | jezdez | I believe pip thinks installing the same version means "no, really, I want to reinstall this version" |
| 00:30 | brosner | yeah, that would make sense and would work fine for our dev builds. |
| 00:31 | jezdez | I hope once we start to use versionlib in pip we don't get any odd edge cases |
| 00:31 | brosner | yeah :/ |
| 00:32 | jezdez | might need to do a compat release |
| 00:32 | jezdez | with a PIP_USE_SANE_VERSIONS switch |
| 00:32 | brosner | any idea on a new virtualenv release? |
| 00:33 | jezdez | nope, I'm out of the loop for pip and venv |
| 00:33 | brosner | i'd love to ship 0.9 final with 2.7 support. |
| 00:33 | jezdez | hm, there wa some kind of refactoring of how site.py is handled |
| 00:33 | jezdez | I think that needs to be done at some point |
| 00:33 | jezdez | the current site.py in venv is horribly outdated |
| 00:33 | brosner | there was a commit that fixed 2.7 (at least it worked in my tests on 2.7a4) |
| 00:34 | jezdez | when is 2.7 about to be released? |
| 00:34 | brosner | June |
| 00:34 | brosner | i expect 0.9 final before 2.7, but having it just work would be killer :-) |
| 00:40 | jezdez | brosner: agreed, we should make it a goal of 0.9alpha2 (or beta) |
| 00:40 | brosner | yep, fine by me. i wasn't expecting an answer now :-) |
| 00:41 | jtauber | what are we agreeing to? |
| 00:41 | brosner | making sure 0.9 runs on 2.7 before release. |
| 00:41 | jtauber | sure |
| 00:41 | brosner | i said though: "i expect 0.9 final before 2.7, but having it just work would be killer :-)" |
| 00:41 | brosner | jtauber: currently the released and bundled version of virtualenv does not work on 2.7 |
| 00:41 | jtauber | it's dangerous to expect 0.9 :-) |
| 00:42 | brosner | if we don't ship 0.9 before June we have problems IMO |
| 00:42 | brosner | something failed |
| 00:43 | jtauber | well, I hope we're there by then |
| 00:43 | jtauber | I think the roadmap is achievable |
| 00:43 | brosner | jezdez: also, what is the status of compressor? |
| 00:44 | brosner | did we need to talk about the issues? |
| 00:44 | jtauber | and what is the status of settings refactor? |
| 00:44 | brosner | working on tonight. |
| 00:44 | jezdez | we should, but I'm slightly, erm, drunk atm |
| 00:44 | brosner | IMO the only blocking issue i can handle myself. which is that uni-form has an @import that is relied on |
| 00:45 | jezdez | mintchaos found a bug in the @import handling though |
| 00:45 | jtauber | I may crash now (although could be up in 4 hours, knowing me) |
| 00:45 | jezdez | brosner: right, it could be related to mintchaos' bug |
| 00:45 | jezdez | |
| 00:45 | brosner | jezdez: oh does it actually try to resolve them? |
| 00:46 | jezdez | not sure, tbh |
| 00:46 | jezdez | carljm might know more |
| 00:46 | brosner | jezdez: the second issue is much more involved |
| 00:46 | jezdez | there is another issue with non-unicode (utf-8) encoded files |
| 00:47 | brosner | i *really* don't like how it handles caching |
| 00:47 | jezdez | basically compressor implies unicode files |
| 00:47 | jtauber | jezdez: do you mean utf-8? |
| 00:47 | jezdez | which isn't a bad choice but can break with jquery plugins from insane windows developers |
| 00:48 | jezdez | yes, utf-8 |
| 00:48 | jezdez | brosner: what don't you like about it? |
| 00:48 | jezdez | the mtime? |
| 00:48 | brosner | each request requires parsing the blocks through BS |
| 00:49 | jtauber | which is BS ;-) |
| 00:49 | brosner | IMO part of the reason why we have a "build" step (build_static) is that it could handle these cases. |
| 00:50 | jezdez | hmm |
| 00:50 | jtauber | yeah, I had hoped whatever solution we went with would just build the static media files and not do that dynamically during runtime |
| 00:50 | jezdez | well, we can't possibly handle it with a mgt command without having to violate DRY and have a list of files to compress in the settings |
| 00:51 | brosner | i understand the concerns about how it should be possible |
| 00:52 | brosner | so, it might be a two part process where build_static invalidates cache and first request deals with the build, but longer relies on mtimes. |
| 00:52 | jezdez | I think there is also a difference in meaning of build_static (actually "collect static files from various locations") and the procesing of media files to create compressed verions |
| 00:52 | brosner | *no longer |
| 00:53 | jezdez | brosner: that would imply a integration with the staticfiles app |
| 00:53 | jezdez | could be done with a signal? |
| 00:53 | jezdez | static_files_rebuilt = Signal() |
| 00:54 | brosner | i'd need to think about it more, but the current way compressor works is slightly unacceptable for a final release of 0.9 IMO |
| 00:54 | jezdez | I agree |
| 00:55 | jezdez | I just think we can make it better |
| 00:55 | brosner | though i am perfectly okay shipping a1 as-is. |
| 00:55 | brosner | well, with the fix for uni-form. |
| 00:56 | brosner | our fix is that the uni-form stuff might as well just be a theme-level concern anyways. |
| 00:57 | carljm | i wonder if there'd be a way to cache the results of the BS parsing based on the template string |
| 00:57 | carljm | the fragment within {% compress %}, i mean |
| 00:57 | brosner | isn't the concern it is trying to solve is that the template code doesn't change, but files do. |
| 00:57 | carljm | well yeah. so you still have to check mtimes |
| 00:58 | carljm | one problem at a time :-) i thought you didn't like the BS re-parsing |
| 00:58 | brosner | so you are referring to caching the files? |
| 00:58 | brosner | *file list |
| 00:58 | carljm | yeah, exactly |
| 00:58 | carljm | just so you don't have to re-parse the template code if it hasn't changed |
| 00:59 | carljm | the mtime check IMO is kinda unavoidable with the way compressor works |
| 00:59 | jezdez | django-compress has a plugable hash implementation: http://code.google.com/p/django-compress/source... |
| 00:59 | carljm | its what you have to do in exchange for the beautiful DRY template api :-) |
| 00:59 | brosner | i think part of this problem can be solved if compressor can use an in-memory cache and not the CACHE_BACKEND which can span process life-cycles |
| 00:59 | jezdez | carljm: yep |
| 01:02 | brosner | if an in-memory cache can be used an option to turn off mtime checks can go away. it doesn't have to be default behavior. |
| 01:03 | brosner | *in-memory ala locmem |