v2.0 prep - FINAL REVIEW - #14
Conversation
- Use the second namespacing technique from PEP382 - `find_packages()` replaces what we were doing manually - exclude `test` directories - add `zip_safe`
Distribute from at least 0.6.26 can handle unicode characters in the package json `description` field (unicode in the `name` breaks). Our custom function however couldn't handle any unicode. It broke with:
```
File "setup.py", line 30, in convert_to_str
d2[k] = str(v)
UnicodeEncodeError: 'ascii' codec can't encode characters ...
```
… from an expected `env_settings.py` file.
… Django environment with the component's settings; it's not just for tests. - `run_django_cmd()` can run any Django command - command line access proxies `manage.py` (so it too can run any Django command) - add loading error messages - `test` is a special case where a) we want to allow specific tests (https://docs.djangoproject.com/en/1.5/topics/testing/overview/#running-tests) b) but default to `TESTED_APPS`
I'm falling back to the current scheme of `tests/` inside the application directory. (Instead of a root level tests directory/app called "tests" initially introduced in this PR.) The downside is that tests will be distributed in the final code (due to packaging in `setup.py`). The upside is tests are contained. The problem I was having is that a root level "tests" app can conflict when testing multiple Armstrong components in the same virtualenv. If the python path has a path for say armstrong.core.arm_content and you switch to arm_sections, the "tests" app might still be pulled from the earlier path entry. Maybe this is a fridge case; maybe it has to do with my `pip install --editable`; it's easier to keep the current expectations and change them later when I'm moving fewer pieces.
…bric tasks into a fabfile.py instead of __init__.py
…alls the component. Replace in favor of an *explicit* install procedure and a decorator that simply halts if the component isn't installed. I'm in favor of explicit installation and clear messaging. Also I don't believe `pip_install` would have ever worked on a fresh virtualenv. It's hard to test with the multiple avenues of package requirement declaration (between setup.py and the requirements files), but I found that if the package path doesn't exist initially that even after the `pip install`, the component couldn't be imported. Run the exact command again, the path would exist and the command would run fine. I didn't want to add complication of `sys.path.append()` or similar methods. Coupled with the new `install` task, this is more explicit. It also allows pip installing this component in `editable` mode so that it doesn't have to be reinstalled into the environment every time you make a change and run a Fabric task. (This is similar to `setup.py develop` if we used Distribute.)
…all when you need it. This will make environment building faster (and this will be helpful in automatic virtualenv creation during testing). This also gets us away from pinning versions which seems weird especially for a dev tool. I've loosen the Fabric version requirement but left `fudge` the same because it hasn't been updated in a while so if/when it does, it may be something we should control. Also by way of oversight, Sphinx wasn't required and is necessary for the `docs` command.
…_name()`. Refactor `create_migration` to use new `run_django_cmd`.
This actually separates the two commands allowing normal `manage.py test` running as well as `coverage`. Change coverage directory spec a bit to make it more flexible. (This will be useful for running coverage across multiple test virtualenvs and keeping separate results.)
…dev) from the virtualenv. Helpful if you are like me and tend to use the same virtualenv when working with different Armstrong components (perhaps not a great practice).
This reverts commit 4cda378.
… confusion causing is greater than its benefit.
…avior. Individual component's should determine if they require fudge (and what specific version they need).
…s already in many `.gitignore` files so use that name.
…cessary as DjangoTestCase doesn't have its own `setUp()` method.
…anteed and I've seen it break with `IntegrityError: column username is not unique`. The new function is more generic and it's a generator. Basically the same fix as armstrong/armstrong.core.arm_layout#14. This is only used in ArmContent, ArmAccess and AppsDonations. The most extensive use is in ArmContent, which is being updated concurrently. Swapping in the new method will be simple.
…nt testing and that is being refactored concurrently.
…lving armstrong#12. Conflicts: package.json
Conflicts: These files are gone in this branch. armstrong/dev/tasks/__init__.py armstrong/dev/virtualdjango/__init__.py
|
Readme and Changes text left. This will land as 2.0 soon. |
|
Anyone want to proofread the new documentation? |
|
I was never that familiar with the armstrong.dev package. Hopefully, I can read my way through this by next Monday. But so many goodies in this. mmmmmmmmmm. |
There was a problem hiding this comment.
spelling: cognizant (there appears to be some debate about this, but the hive mind seems to prefer z)
|
Thanks! I'll wait until next week for anything final. There is definitely a lot going on here but the individual PRs and commits break it down. |
… default, exclude South migrations.
…(which we don't use, but it's a good idea so add it to the Readme).
… is the current case for each individual component.
|
@crccheck need any extra time? Thoughts? I also added two settings changes. |
|
I'm looking over this now. Forgive my ignorance, but is there code to run? or am I just reading? |
|
Nice catch. You pose a good question--the best way to give it a run-through is probably to download AppsEmbeds tarball, download this, and replace the first line in Then for some things to do:
|
|
Are those commands working? Are you enjoying dramatically faster virtualenv builds? |
|
so far so good. I'm looking into the invoke collection right now. Trying to see the tradeoffs between what you did (importing armstrong.dev's tasks into the app's tasks) versus using invoke's built int Collection logic. But know what? the exact result would be the same and what you have already works. So forget that. |
example: "ERROR armstrong.core.arm_layout--backend error text" is more conclusive than "ERROR basic--backend error text". Since anything could be logging, it's better to know the logger name.
|
fyi: just ran |
|
I went through the motions of setting up a |
|
Are you talking about this? https://github.com/armstrong/pypi.armstrongcms.org Though I did use it recently to get a three year old Django-reversion for our sadly current ArmContent. |
|
oh yeah haha, that's it. also, i have no idea what arm content is. |
|
newer pip makes installing from unsigned sources a pain. I don't now if On Wednesday, March 19, 2014, crccheck notifications@github.com wrote:
|
|
i have the latest reversion going on cir. can share. On Wednesday, March 19, 2014, Jon Cotton notifications@github.com wrote:
|
|
There's a lot of work to get ArmContent up to speed. It's the largest and most central of Armstrong components so that makes sense, but it has some mess to it as well. What's funny is Reversion is required but not used. Here's the todo so far: armstrong/armstrong.core.arm_content#32 |
|
Release time? |
|
|
3 participants
This is the monster diff of all 2.0 work in one place. The work consists of, in much more manageable chucks, the following:
Left to do:
This will merge to a branch in the main repo and from there to master where it'll become the new 2.0 release.