Re: Migrations and Reusable Apps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/17/2014 10:05 AM, Andrew Godwin wrote: > 1.7 is not going to be a pretty release for third-party apps for a > number of reasons: this, the app-loading refactor, the changes to custom > fields, and a few other things. I might leave an open offer of help > upgrading from myself after the release to any app maintainers to try > and smooth that process along. +1 that. This has been the hardest recent release for my own apps (mostly because of the app-loading refactor). I'm grateful for the help I received while migrating django-simple-history to 1.7. Sign me up for that offer also. I can help out with 1.7 support advice as my abilities allow. - -- Trey Hunner http://treyhunner.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJToHv2AAoJEOpnfp/NreonGzoIAMOpD4xBRiZDDfw1WwuHqVBd mrq/VbyA7iTGMzQZ0ZSXhUT4Qd1dR0T1k0Qcyaeg837GdufkL4ikj8mFXHIRVAes pXHYkV2W3NI8J6VqPDw1fB41nNcFxa7q/1GoABT0yLsAAfCu6v2WNpx+qipFmI7g 6ugpL7fa+9lqd2K2bDsgW9s0UR/Z67DenpCdmYN9kFk8h49c+B/v/EbDV89qT3tg pogtGKE/UOsvQG76v4BEcQmnQkAKNPzY9jFFb8wkhgzwkBj6tTXhbuqRw2TDhkKH ORJj5xEKrIeSflFHqb4wT2zjlOMpyW3dwDs+X0PUe8mU0ZhPhpvtVFgWjA1aDOw= =Marr -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/53A07BF6.3090008%40treyhunner.com. For more options, visit https://groups.google.com/d/optout.
Re: Migrations and Reusable Apps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Mark, I've left replies inline below. Note that I am not heavily involved with South development nor the Django 1.7 release so my perspective may be skewed from reality. On 06/17/2014 06:18 AM, Mark Lavin wrote: > Given that contrib.auth now has migrations and many reusable > applications have FKs to the User model, doesn't this force most > reusable applications to ship migrations > in order to be compatible with 1.7? Is this an unintended consequence or > an expected requirement? I know the plan is to eventually require > migrations but this > seems like a hard requirement which could make upgrading to 1.7 more > difficult due to lagging dependencies. Reusable apps should add Django 1.7 migrations if they have none. Going from no migrations to Django 1.7 migrations is much easier than going from South migrations to 1.7 migrations (assuming South compatibility should be maintained). > Is there an acceptable approach for a reusable application to support > 1.6 + South and 1.7 + db.migrations? > This http://treyhunner.com/2014/03/migrating-to-django-1-dot-7/ seemed > like a good approach though it does highlight the backwards > compatibility issues. There have been a few more developments since I wrote that blog post. Andrew and I discussed the idea of supporting a south_migrations module in the next release of South. This would allow that special south/__init__.py code to be removed so long as users were asked to upgrade to the latest version of South. Relevant south-users mailing list thread: https://groups.google.com/forum/#!msg/south-users/YW7zQ1KeuvM/o-EzlEQX4jsJ Relevant discussion on the django-email-log pull request: https://github.com/treyhunner/django-email-log/pull/8 > > Best, > > Mark > > -- > You received this message because you are subscribed to the Google > Groups "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to django-developers+unsubscr...@googlegroups.com > <mailto:django-developers+unsubscr...@googlegroups.com>. > To post to this group, send email to django-developers@googlegroups.com > <mailto:django-developers@googlegroups.com>. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/afd7da9e-02e3-4c80-bef9-71dac036c415%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/afd7da9e-02e3-4c80-bef9-71dac036c415%40googlegroups.com?utm_medium=email_source=footer>. > For more options, visit https://groups.google.com/d/optout. - -- Trey Hunner http://treyhunner.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJToG6eAAoJEOpnfp/Nreon0gEH/2cwlY4xvoPKK5IjQA/opb75 umcsQDwc479iHXMUIHt91IirvMRt7Mt4AyO8RxyHMymF3Rfn3kHvHpdjIvwuz4b3 smr8ddIbtK33JfvO2HFESSnIuV+o2znjduaZRbAXMzAyPKb0w1IrcHyxl+HIwOHB FkkQs2zWdexmg3RhnhBq20cy7qqolsKGPBkQzSyQjkiWyaoDfh6gKsOWO8wRurZa NR0G3L/buOCDUAdrmCee8JWbESPqWU3PqPoSCv9y0A2Zy9g1v7rrbj9Y/aczx3ME LYacXeYLdOcXgMAvWOGw4grzqSFsUclMfM+pzPBu6DDY1TGwgtFIx+FcJDvwkRo= =Vdz5 -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/53A06E9E.1060705%40treyhunner.com. For more options, visit https://groups.google.com/d/optout.
Re: Great Wall of DEP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/29/2014 08:58 PM, Michael Manfre wrote: > From DEP 001: > > "Once you've written a DEP and submitted the pull request, post a > message about it to the django-developers mailing list. At that point, > Django developers will make sure it's technically feasible, not spam, > etc., assign it a DEP number and commit it to the repository as > "Active." This doesn't mean the feature will be implemented; it merely > means the proposal is officially a DEP." > > There are two DEP pull requests that seem to have sat for two weeks > waiting to be merged in as "Active" with numbers assigned. They are both > clearly not spam and are technically feasible. I'm curious why they have > not been moved along in the process. I'm not convinced that the open pull requests are a problem. I don't see any comments on any of the pull requests stating that a DEP seems ready to be merged. Maybe the problem here is an unclear/absent process for merging? I would think merging should purposely be delayed because once the DEP is merged it is no longer active unless a new pull request is made to modify it. The current process assigns a number only after the pull request has been merged. I'm not sure those two steps should be related. Assignment of a DEP number could happen *before* the pull request is merged. How does the PEP process handle this? Are threads ever declared "done" and if so is that finalization separate from the assignment of a PEP number? - -- Trey Hunner http://treyhunner.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTbQZ7AAoJEOpnfp/NreonXkwH/jRsO7gcc6HX5b1kdZmGpoOO 92sX9gtjYiX8NwkEwjQaTAOGGCLhxZXnvwN1IMdjMR4ogE7rs9vg0Uc4hML0UYYL 1zijA8sxJF4ZeuIgAk/hFIRfOHVfAkJUaSdkAtVijH3VPX8wvd/NqAr5zlGn/e9b 0DsvA5OczZea6VvqllZfqQVJ6KJA7lfDWjf6PRKGnWl+Daxi9ygkhUV7E0pyt/qZ wqV6jSBqvNkoT/QPdpXnXvKd8ZkG8KtOw+VYuJJb3cf2guUXdwy9tHX6Lmlm2IMR AhCnRHJPAqqVRDhswocFJCJ1tIUjObnb2rVsxgwh11PrcNhLz7z/MS7rN3M+lcQ= =TmrW -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/536D067B.8010104%40treyhunner.com. For more options, visit https://groups.google.com/d/optout.
Re: Great Wall of DEP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Adding my two cents below regarding DEPs. On 05/08/2014 05:49 AM, Łukasz Rekucki wrote: > Discussing DEPs on Github inside Pull Request comments seems like a > really bad idea, because it excludes a whole bunch of people that are > subscribed to this list (I always thought this was the sole purpose of > this list). I just submitted a DEP and I actually preferred the pull request method over an email thread. I like the pull request method because I am more likely to open a pull request or comment on a pull request than to send an email to this mailing list. Sending an email seems like a big deal because it's set in stone and making a correction to it requires sending at least one follow up email. I also like that a pull request is available for reading and feedback without being buried by mailing list threads. My DEP hasn't been updated in 4 days because I've been busy, but others can still easily find it by scanning the pull requests page on the DEPs repository. > The best thing about PEPs is that they always get posted to python-dev > in *full text* and the discussion happens there. The email thread then > gets recorded inside the PEP so that 10 years later you can easily > read the whole discussion. Github comments don't have this feature, > really. Maybe this system should be setup as a two stage process: 1. Create a DEP and make small revisions on the pull request based on feedback and new insights 2. Post to the mailing list after milestone changes, possibly copying the full DEP text or by just referencing the URL and overview of the DEP That way both the mailing list and deps repository watchers would stay informed, but the mailing list would only hear about larger changes. - -- Trey Hunner http://treyhunner.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTbQWvAAoJEOpnfp/NreonUtIH/02Cqj8FTK+OD4wd3QZrCIgb llvz3pgUmCAurZ/zJAbK9AykA5JwtlCRampGrU/JzxcKB0LmstCVrUEE5WHavup9 gWfqCtoF/QBnY3wqLWnkBi8/fposfoyhLCLzGx9K0SP/Hsrr+N4ZnvaTprVWQTtQ HYj5SQx8be53KAFF7nbgCl06Rg8Pah9wxMAxbt/wx1VeD9MIIyDsX0Iiv9Sms5Ru ZPpefsmjXbBjWWGizZ5kYLH/092GhrFM3pG1udCDVlcgBa5s0pDI3ch+TfL6eLuQ XsxVKUHP+n67f72EvNxpFRwZvwNqYXivuxojf8PYeivlv014v9cbXMbaWHhm5hA= =2QVT -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/536D05AF.7060605%40treyhunner.com. For more options, visit https://groups.google.com/d/optout.
Re: Proposal: Write unit tests for JavaScript
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I started a rough draft of a DEP for adding unit tests for Django's JavaScript: https://github.com/django/deps/pull/4 I am suggesting that a native JavaScript test framework be used *without* attempting to use an adapter to run the tests under the Django test framework. I anticipate that this suggestion may require further explanation and debate, so I have submitted a pull request for discussion while I continue to extend the DEP. - -- Trey Hunner http://treyhunner.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTZy2KAAoJEOpnfp/Nreona8oIAKBE0T05wmnCP0tq/nvmQIlC 0KWB0bX47FHn3TeOjEK8dHrxebP9UDL+wmdZ8F23iOQnW8OiJIO3dJjSjqLOAXxg dNh5imq02kY2rvjVB6ypZp0h+INkQoaQMae5xMdN4RozLnbNrgXln7vbuSrjIB/8 z7h983vqiRp/ofa+2urTnUnC63730gg6vBbXE5EQ+5WeJxqx2yahdbeSmB3oCnhD 7TMRdHYY+Tx1bdsHF3KOniKoHXA0qoeV16RK+J7EWRHMo3eKlH1zOpcbNX8klwed qF2zZSKFqMIj0H/mBOVWy5uePXUOfIOP4iLTjEuSy+6sPDNPCiPAvCE5R9jyz/k= =/i9B -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/53672D8A.2050005%40treyhunner.com. For more options, visit https://groups.google.com/d/optout.
Re: Proposal: Write unit tests for JavaScript
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Kamil, I started another thread related to JS linting: https://groups.google.com/forum/#!topic/django-developers/GUgRMnnC0dM Here is a related pull request: https://github.com/django/django/pull/2577 I have not yet changed the code style of any JavaScript files because I wasn't certain what style should be used. At this point I think the jshint tool should be used to enforce the default JSHint code style. If style exceptions arise then they can be documented in the .jshintrc file and re-factored later. On 04/22/2014 04:31 AM, Kamil Gałuszka wrote: > Hi Trey, > > You may be interested in this: > https://code.djangoproject.com/ticket/20436 > > I've started to work on this last year on DjangoCon Europe, I never > manage to finish my work mostly because of my work on thesis and other > stuff. > > Maybe I will finish this ticket this week and you start writing UnitTest > for that? > > Cheers > Kamil Gałuszka > > On Saturday, April 19, 2014 1:50:19 PM UTC+2, Jannis Leidel wrote: > > Hi Trey, all, > > I know we shortly talked about that at PyCon but I forgot to mention > that a while ago we took a stab at that already. Sean Bleier was spear > heading it and I helped out here and there: > https://github.com/sebleier/django/compare/4f3ad28a9b4ffc3ae9866d14f242844d5720b3be...qunit > <https://github.com/sebleier/django/compare/4f3ad28a9b4ffc3ae9866d14f242844d5720b3be...qunit> > > > Sadly we never finished it, even though it was supposed to be merged > together with the LiveServerTestCase. It was providing a "jstest" > management command that was just runserver in disguise with an > enforced URLconf with a few views to render JS test pages. > > The actual core part was a collector for JS test suites > (conventionally placed in /tests/javascript). Each suite could > test any kind of local and remote files and used staticfiles for > serving them. > > I'm not suggesting to re-use this code but wanted to mention that > we've worked on it and found it pretty good (at the time). We just > lacked the time to finish it. Also, some parts are specific to QUnit > but others (like the suite collector) could be reused for other test > runners. > > All in all, I'm all for supporting some way for writing JS tests as > part of Django apps but would be a lot more careful about what > technique/tool to use given the fast paced changes in JS land. I admit > I don't have experience with Jasmine though so take my advise with a > grain of salt :) > > Cheers, > Jannis > > > On 16.04.14 23:57, Trey Hunner wrote: >> I saw a previous discussion about JavaScript testing in Django but >> it looks like there hasn't been any progress in a few years. > >> Some of my thoughts on this issue: > >> This would require choosing a JavaScript testing framework. There >> are many good ones out there. A popular one should probably used >> for easier community support. > >> Unit testing JavaScript (ideally) should not require running the >> Django server. > >> JavaScript tests will probably require introducing Node.js into >> the automated testing process. Tests can be run manually from the >> browser, but automated JavaScript tests tend to require Node.js and >> sometimes PhantomJS (for headless testing). > >> The JavaScript tests should be run as part of the CI testing >> process. If the tests are run standalone this should be easy to do >> using a single command (possibly requiring grunt or a similar task >> runner). > >> This seems like it would be a big change, but I think it could be >> done in small steps. Setting up the testing framework is the first >> big step. > >> What do others think about this issue? > >> -- Trey Hunner > >> -- You received this message because you are subscribed to the >> Google Groups "Django developers" group. To unsubscribe from this >> group and stop receiving emails from it, send an email to >> django-develop...@googlegroups.com >> <mailto:django-developers+unsubscr...@googlegroups.com > >. To post to >> this group, send email to django-d...@googlegroups.com >> <mailto:django-d...@googlegroups.com >. Visit this > group at >> http://groups.google.com/group/django-developers > <http://groups.google.com/group/django-developers>. To view this >> discussion on the web visit > > https://groups.google.com/d/msgid/django-developers/CACuWcAwHVJ7HfeWOui3pAT3nQJeABP_Vt5WQe1N5%2BvDs%2Bnt8GQ%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CACuWcAwHVJ7HfeWOui3pAT3nQJeABP_Vt5WQe1N5%2BvD
Re: Proposal: Write unit tests for JavaScript
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks for the information Jannis. I hadn't realized that project got to the point of a pull request. Personally I prefer running unit tests without LiveServerTestCase. It seems like LiveServerTestCase should be used for functional tests (using selenium) and not unit tests. I had not anticipated taking up the task of creating a custom Python-based test harness for JavaScript tests. I am not necessarily opposed to this idea, but it seems like a complex solution to a simple problem. I'm more concerned with getting the JavaScript properly tested than I am with creating a Python-powered JavaScript test harness. I think that problem (if it is one) could be resolved later without much hassle in migration. I disagree with Marc's suggestion that being able to run both Python and JS tests at the same time "must be better". I see these tests as distinct from the Python tests. I am certainly biased from my past experience attempting to run JavaScript tests through Python and giving up in favor of the more common solution of using Node and PhantomJS. The great thing about JavaScript tests is that they just run in HTML files, so if JS unit tests are run through PhantomJS and Node initially they can be migrated to use a Selenium and Python wrapper later if desired. Also, regardless of the solution chosen, it should always be possible to manually run the tests with a web browser. Sorry for the gap in my reply time. I have been busy this week and haven't had time to put together a DEP yet. On 04/19/2014 04:50 AM, Jannis Leidel wrote: > Hi Trey, all, > > I know we shortly talked about that at PyCon but I forgot to mention > that a while ago we took a stab at that already. Sean Bleier was spear > heading it and I helped out here and there: > https://github.com/sebleier/django/compare/4f3ad28a9b4ffc3ae9866d14f242844d5720b3be...qunit > > Sadly we never finished it, even though it was supposed to be merged > together with the LiveServerTestCase. It was providing a "jstest" > management command that was just runserver in disguise with an > enforced URLconf with a few views to render JS test pages. > > The actual core part was a collector for JS test suites > (conventionally placed in /tests/javascript). Each suite could > test any kind of local and remote files and used staticfiles for > serving them. > > I'm not suggesting to re-use this code but wanted to mention that > we've worked on it and found it pretty good (at the time). We just > lacked the time to finish it. Also, some parts are specific to QUnit > but others (like the suite collector) could be reused for other test > runners. > > All in all, I'm all for supporting some way for writing JS tests as > part of Django apps but would be a lot more careful about what > technique/tool to use given the fast paced changes in JS land. I admit > I don't have experience with Jasmine though so take my advise with a > grain of salt :) > > Cheers, > Jannis > > > On 16.04.14 23:57, Trey Hunner wrote: >> I saw a previous discussion about JavaScript testing in Django but >> it looks like there hasn't been any progress in a few years. > >> Some of my thoughts on this issue: > >> This would require choosing a JavaScript testing framework. There >> are many good ones out there. A popular one should probably used >> for easier community support. > >> Unit testing JavaScript (ideally) should not require running the >> Django server. > >> JavaScript tests will probably require introducing Node.js into >> the automated testing process. Tests can be run manually from the >> browser, but automated JavaScript tests tend to require Node.js and >> sometimes PhantomJS (for headless testing). > >> The JavaScript tests should be run as part of the CI testing >> process. If the tests are run standalone this should be easy to do >> using a single command (possibly requiring grunt or a similar task >> runner). > >> This seems like it would be a big change, but I think it could be >> done in small steps. Setting up the testing framework is the first >> big step. > >> What do others think about this issue? > >> -- Trey Hunner > >> -- You received this message because you are subscribed to the >> Google Groups "Django developers" group. To unsubscribe from this >> group and stop receiving emails from it, send an email to >> django-developers+unsubscr...@googlegroups.com >> <mailto:django-developers+unsubscr...@googlegroups.com>. To post to >> this group, send email to django-developers@googlegroups.com >> <mailto:django-developers@googlegroups.com>. Visit this group at >
Re: Proposal: Write unit tests for JavaScript
> On 04/16/2014 07:20 PM, Russell Keith-Magee wrote: > > 2) Is there anything that can save us from the Node.js kudzu? :-) Yes. Removing JavaScript from Django. :-) JSHint requires Node.js and running automated JavaScript tests typically requires Node.js and PhantomJS. Node.js is pretty easy to install and it would only be required for JavaScript linting and automated testing. You wouldn't necessarily need Node.js to manually run the tests locally in a browser, but you would need it for running tests from the command line. > You've definitely identified that this is a long term project; so if you > can lay out a map for the way forward, with an indication of the end > goal, that would be a fantastic start IMHO. Agreed. I will try formulating a more concrete proposal. I work full-stack but I have limited experience with JavaScript testing frameworks, so my personal preferences include a sample size of one. I will try to keep my suggestions to the community standards as I perceive them. On Thu, Apr 17, 2014 at 10:30 AM, Carl Meyer <c...@oddbird.net> wrote: > > A DEP might be a good format to summarize the thinking that goes into > picking a particular tech stack for JS tests. I will look at the DEPs and try to propose a concrete example there. > (FWIW, on my company's projects we unit-test JS using Node, PhantomJS, > Grunt, QUnit, and Istanbul for test coverage measurement, so that's the > stack I'm familiar with. It's worked very well for us; there's a > grunt-qunit-istanbul plugin that brings the pieces together nicely. But > I didn't make those choices and am not familiar with the alternatives; > there may be better options.) I have a very similar setup. I chose qunit because it seemed popular among front-end JavaScript projects and because jQuery uses it. QUnit and Jasmine seem like the winners in this space at the moment. We may also want to consider looking at the Karma test runner by the Angular.js team (it supports a number of test frameworks including QUnit and Jasmine). I know little about it, so feedback on this would be helpful. This may be something that can be added later. I analyzed the test runners used by the top 12 front-end JavaScript libraries on Github (according to the API). Here are the numbers: QUnit test framework is used by: - Backbone - Ember.js - Knockout - Reveal.js - jQuery - three.js - jQuery-File-Upload Jasmine test framework is used by: - Knockout - Spine - Brackets - Angular.js (using Karma) Vows test framework is used by: - d3 I'll start working on that DEP. -- Trey Hunner -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CACuWcAxsRN6YwSM5GfA42TEgMv3cWeJ27L3gW5Yh%2Bpm5ASwMag%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Proposal: Write unit tests for JavaScript
I saw a previous discussion about JavaScript testing in Django but it looks like there hasn't been any progress in a few years. Some of my thoughts on this issue: This would require choosing a JavaScript testing framework. There are many good ones out there. A popular one should probably used for easier community support. Unit testing JavaScript (ideally) should not require running the Django server. JavaScript tests will probably require introducing Node.js into the automated testing process. Tests can be run manually from the browser, but automated JavaScript tests tend to require Node.js and sometimes PhantomJS (for headless testing). The JavaScript tests should be run as part of the CI testing process. If the tests are run standalone this should be easy to do using a single command (possibly requiring grunt or a similar task runner). This seems like it would be a big change, but I think it could be done in small steps. Setting up the testing framework is the first big step. What do others think about this issue? -- Trey Hunner -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CACuWcAwHVJ7HfeWOui3pAT3nQJeABP_Vt5WQe1N5%2BvDs%2Bnt8GQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Proposal: document and enforce style of all files (including JS, CSS, HTML)
The JavaScript files use 4 spaces, 2 spaces, or tabs (depending on the file). The CSS files use mostly 4 spaces, and the HTML files use mostly 2 spaces and sometimes 4 spaces. The JavaScript code is unlinted and the general code style is neither documented nor enforced. I think jshint should be used for JavaScript linting and to help clean up the JavaScript code. It should also be built into the test process (via running "jshint ."). Optionally, it could also be run automatically through tox or a fabric/invoke/grunt configuration. I opened a ticket and pull request related to this issue: https://code.djangoproject.com/ticket/22463#comment:2 Based on the errors I've seen in the JavaScript code so far, I think a code review may be sufficient for ensuring that the changed files continue to work as expected. -- Trey Hunner -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CACuWcAwrCq_q4%2BFkKOVU5nqokSSgM7wqzXPbo%2BKJh0U%3DY1ecVA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Combine localflavor apps again
On Tuesday, May 21, 2013 5:51:11 AM UTC-7, Jannis Leidel wrote: > So what I propose to fix this is simple: > > - combine the localflavor packages into one Python package again, call it > django-localflavor > - give all the individual country maintainers also access to that package > - have a central documentation, e.g. django-localflavor.readthedocs.org > - update the Django docs to point to that package > - ask the maintainers of the 7 already released packages to point to the > newly created django-localflavor I am also for this. However, if the django-localflavor merge doesn't occur, at a minimum the django-localflavor-* ecosystem needs: - A procedure for requesting access to maintain a django-localflavor-* variant - A project for maintaining suggestions and guidelines for django-localflavor maintainers (e.g. use PyPI, add South rules, use tox) - Relevant links to procedures and guidelines in every django-localflavor-* README file I volunteer help merge changes for the django-localflavor-us variant if help is needed. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: I am interested in maintaining django-localflavor-us
I'm treyhunner on Github. Thanks Jacob. On Monday, May 20, 2013 3:14:59 PM UTC-7, Jacob Kaplan-Moss wrote: > > No objections from me. What's your GitHub username? I'll hook you up. > > Jacob > > On Mon, May 20, 2013 at 3:10 PM, Trey Hunner > <tr...@treyhunner.com> > wrote: > > The django-localflavor-us package currently lacks a responsive > > maintainer. I would like to fix this problem by helping to maintain > > this project. > > > > My primary goals: > > > > * Make the tests easier to run > > * Merge good pull requests > > * Add instructions for contributing (namely how to run the tests) > > * Ensure the project stays up-to-date on PyPI > > > > I already uploaded the project to PyPI. I can't help much more > > currently without commit access or someone with commit access to > > comment on and merge pull requests. > > > > -- > > Trey Hunner > > > > -- > > You received this message because you are subscribed to the Google > Groups "Django developers" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to django-develop...@googlegroups.com . > > To post to this group, send email to > > django-d...@googlegroups.com. > > > Visit this group at > http://groups.google.com/group/django-developers?hl=en. > > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
I am interested in maintaining django-localflavor-us
The django-localflavor-us package currently lacks a responsive maintainer. I would like to fix this problem by helping to maintain this project. My primary goals: * Make the tests easier to run * Merge good pull requests * Add instructions for contributing (namely how to run the tests) * Ensure the project stays up-to-date on PyPI I already uploaded the project to PyPI. I can't help much more currently without commit access or someone with commit access to comment on and merge pull requests. -- Trey Hunner -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
django-localflavor-* issue tracker clarifications
It's unclear whether issues for the django-localflavor-* repositories should be submitted on Github or via the main Trac issue tracker. I think this should be clarified in the README file for each django-localflavor-* repository. There has been an open issue on the django-localflavor-us package for 3 months noting that it isn't on PyPI. I just registered django-localflavor-us on PyPI and released a source distribution today. Who should I turn over PyPI access to? -- Trey Hunner -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
