Re: virtual fields and the migration framework

[Federico Capoano]

Hi Markus,

thank you very much for your suggestion. I'll try it later this afternoon 
and come back to report.

Federico


On Wednesday, April 22, 2015 at 12:54:32 AM UTC+2, Markus Holtermann wrote:
>
> Hey Federico,
>
> I just had a brief look at the code. If I understand 
> the HStoreVirtualMixin.contribute_to_class() correctly and its implications 
> regarding add_field(), I'd try to use cls._meta.add_field(self, 
> virtual=True) instead of a simple cls._meta.add_field(self). That way the 
> virtual fields shouldn't show up in migrations at all: 
> https://github.com/django/django/blob/master/django/db/migrations/state.py#L357
>  
> -- The way the e.g. DictionaryField is implemented, when you put the schema 
> into the deconstruct() output, contribute_to_class() should still be called 
> generating the additional fields on its own.
>
> Note that this is just a shot in the dark. I didn't try it out myself.
>
> /Markus
>
> On Tuesday, April 21, 2015 at 7:53:04 PM UTC+2, Federico Capoano wrote:
>>
>> Hi everyone,
>>
>> some time ago I submitted this ticket: 
>> https://code.djangoproject.com/ticket/23159 - because we had problems 
>> with the migration framework.
>>
>> To sum up, the django-hstore 
>>  library has a 
>> VirtualField implementation which maps hstore keys (by supplying a schema 
>> parameter) to virtual fields so that they can be used on models, the admin, 
>> and even in django-rest-framework APIs. 
>>
>> After some interactions with Andrew Godwin, I implemented his suggestion, 
>> that was to let db_type() return None, which worked well, until this other 
>> issue came up: https://github.com/djangonauts/django-hstore/issues/103
>>
>> In that case the migration framework would throw an error even if db_type 
>> returned None.
>>
>> Luckily, Tim Graham suggested me how to reach the no-op branch of the 
>> migration framework: 
>> https://github.com/django/django/blob/190afb86187e42c449afe626cff31f65b4781aa2/django/db/backends/base/schema.py#L470-L475
>>
>> I met Florian Apolloner at Pycon Italy, so I took advantage of his 
>> presence to ask some questions and hear some feedback, which I really 
>> appreciated and which really helped me.
>>
>> I have been able to replicate the bug in a test case and implement the 
>> workaround, now comes the interesting part: here's the workaround code:
>>
>> https://github.com/djangonauts/django-hstore/commit/47f5aa05834365e2d6c41234e03b028a827ee91c
>>
>> As you can see, I had to add quite some ugly code just to enter that 
>> no-op branch there must be a better way! :-D
>>
>> I talked with Florian about the possibility to have some way to flag 
>> virtual fields in order to enter that no-op branch more easily and he was 
>> not very sure about it but nonetheless he encouraged me to bring up this 
>> issue here. One of the reasons he was not sure is "what happens if a field 
>> has the skip flag and then it doesn't or viceversa?"
>>
>> So I thought about proposing a definition of virtual field:
>>
>> "A virtual field is a model field which it correlates to one or multiple 
>> concrete fields, but doesn't add or alter columns in the database."
>>
>> By following this definition I suppose we can:
>>
>>- allow the migration framework to enter the no-op branch if 
>>analyzing a virtual field
>>- if a concrete field becomes virtual (i can't immagine the use case 
>>but i'm reasoning just in case), the migration framework will drop the 
>>column, and the developer will have to adjust the migration in order to 
>>avoid losing data
>>- if a virtual field becomes concrete, the migration framework will 
>>add the right column and the developer will have to adjust the migration 
>> in 
>>order to correctly fill the concrete field with the data that is probably 
>>stored in another concrete field
>>
>> Thank you for your attention.
>> Best regards
>> Federico Capoano
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/c7ef8579-4ba8-4386-8601-ef4d6f376d78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Idea/request for help: Django Developers Community Survey

[Federico Capoano]

Great idea.
The questions look good enough to me.

I love django-apps or libraries shipped in python packages. One of the 
reason I love Django is the fact that it didn't frenetically add stuff to 
the framework just because it's cool.
The good thing of python packages is that you can get some data from pypi 
(downloads) and github (clones). But we can't do that with contrib apps 
unfortunately.

Federico


On Saturday, April 18, 2015 at 1:00:13 AM UTC+2, Tim Graham wrote:
>
> I had an idea to conduct a survey to get a sense of how developers are 
> using Django. I first had the idea when the question of maintenance of the 
> Oracle GIS backend came up. We really have no idea whether or not anyone is 
> actually using that backend, and it would be helpful to know so we are not 
> wasting resources on unused features. Also there's the question of how 
> often to release Django. I think it would be nice to make that decision 
> based on some data from the community.
>
> Is anyone is interested in coordinating such a survey (collating 
> questions, preparing the online survey, etc.).
>
> Some question ideas to get started:
>
> Which database backend(s) do you use?
> [ ] Checkbox for each one
>
> Which contrib apps do you use?
> [ ] Checkbox for each one
>
> How often would you like to see new major version of Django released?
> [ ] List some options, probably between 6 and 9 months.
>
> Describe which version of Django you use (check all the apply):
> [ ] I only use long-term support releases.
> [ ] I upgrade to the latest stable version as quickly as possible.
> [ ] I run off of master.
> [ ] I upgrade Django when the version I am using is nearing the end of its 
> support (or after).
> [ ] I don't bother upgrading Django, even if it becomes unsupported.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/8a4ac444-2b4e-4321-ad34-8e8e6f8131ad%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pass exception to error handlers

[florent . pastor]

I find this interesting too. It could be very useful when using custom 
exception in the model.

On Tuesday, April 21, 2015 at 8:58:59 PM UTC+1, Claude Paroz wrote:
>
> Here is some code to demonstrate a possible implementation:
>
> https://github.com/claudep/django/commit/5617d32e8f10861fb84bf26297dfcd4e4e40d6d7
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/a334d91e-e515-4ae8-bc73-8d5a1a6c1f8b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Suggestions on a form library

[James Pic]

You should use something like bitbucket or github.

Did you check existing form libraries like django floppy forms or
django crispy forms ?

I think this belongs to django-users as well.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/CALC3KadKW%2BmvPvSnaqpB7-8XUN2XXYPWTFyZnu9CVmHHkxNQJA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Altering migration operations depending django.Version (3rd party apps)

[Patrick Craston]

Hi all

I'm creating a migration for a 3rd party app that needs to work with 
current and previous Django versions. In Django 1.8 "makemigrations" adds a 
"AlterModelManager" operation which only works with Django 1.8 and later 
since AlterModelManager didn't exist before. It will also do an AlterField 
to convert the IPAddressField to GenericIPAddressField.

I currently have this: 
https://gist.github.com/anonymous/e4d7f4f6dfd48988640d

Basically I append to migrations operations if django.VERSION >= (1,8). But 
as was mentioned in #django IRC, if the user applies the app's migration in 
Django 1.7 those migrations don't get applied. If the user then upgrades to 
Django 1.8, the user would miss those migrations?

Is there a recommended way of altering migration operations depending on 
django.VERSION? If yes, do you think it might be worth adding a note in the 
documentation?

Thank you!
Patrick

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/ed634f4d-5993-4343-8aae-a5069d833ed2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Altering migration operations depending django.Version (3rd party apps)

[Tim Graham]

The recommended way is to run makemigrations with the lowest version of 
Django you wish to support. As this recommendation hasn't been tested, let 
us know if you encounter any problems with it. A potential problem that 
comes to mind is if you have an EmailField which had its default max_length 
increased to 254 characters in 1.8. If you run makemigrations using 1.7, 
you won't get a migration to increase the length of that column. The best 
solution is probably to add an explicit max_length=254 to such fields.

https://docs.djangoproject.com/en/1.8/topics/migrations/#supporting-multiple-django-versions

On Wednesday, April 22, 2015 at 7:32:48 AM UTC-4, Patrick Craston wrote:
>
> Hi all
>
> I'm creating a migration for a 3rd party app that needs to work with 
> current and previous Django versions. In Django 1.8 "makemigrations" adds a 
> "AlterModelManager" operation which only works with Django 1.8 and later 
> since AlterModelManager didn't exist before. It will also do an AlterField 
> to convert the IPAddressField to GenericIPAddressField.
>
> I currently have this: 
> https://gist.github.com/anonymous/e4d7f4f6dfd48988640d
>
> Basically I append to migrations operations if django.VERSION >= (1,8). 
> But as was mentioned in #django IRC, if the user applies the app's 
> migration in Django 1.7 those migrations don't get applied. If the user 
> then upgrades to Django 1.8, the user would miss those migrations?
>
> Is there a recommended way of altering migration operations depending on 
> django.VERSION? If yes, do you think it might be worth adding a note in 
> the documentation?
>
> Thank you!
> Patrick
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/42ee9e84-4160-46fd-b396-bb273a7a7e4c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Altering migration operations depending django.Version (3rd party apps)

[Patrick Craston]

Hi Tim

If I create a migration on the lowest Django version I wish to support (say 
1.7), it will not add the AlterModelManager operation to the migration. If 
someone installs the app on Django 1.8, the migration will run fine. 

However, every time the user runs "migrate" after that it will complain 
about the models having changes that are not reflected in a migration and 
ask the user to run "makemigrations" which doesn't seem right?

On Wednesday, 22 April 2015 13:13:40 UTC+1, Tim Graham wrote:
>
> The recommended way is to run makemigrations with the lowest version of 
> Django you wish to support. As this recommendation hasn't been tested, let 
> us know if you encounter any problems with it. A potential problem that 
> comes to mind is if you have an EmailField which had its default max_length 
> increased to 254 characters in 1.8. If you run makemigrations using 1.7, 
> you won't get a migration to increase the length of that column. The best 
> solution is probably to add an explicit max_length=254 to such fields.
>
>
> https://docs.djangoproject.com/en/1.8/topics/migrations/#supporting-multiple-django-versions
>
> On Wednesday, April 22, 2015 at 7:32:48 AM UTC-4, Patrick Craston wrote:
>>
>> Hi all
>>
>> I'm creating a migration for a 3rd party app that needs to work with 
>> current and previous Django versions. In Django 1.8 "makemigrations" adds a 
>> "AlterModelManager" operation which only works with Django 1.8 and later 
>> since AlterModelManager didn't exist before. It will also do an AlterField 
>> to convert the IPAddressField to GenericIPAddressField.
>>
>> I currently have this: 
>> https://gist.github.com/anonymous/e4d7f4f6dfd48988640d
>>
>> Basically I append to migrations operations if django.VERSION >= (1,8). 
>> But as was mentioned in #django IRC, if the user applies the app's 
>> migration in Django 1.7 those migrations don't get applied. If the user 
>> then upgrades to Django 1.8, the user would miss those migrations?
>>
>> Is there a recommended way of altering migration operations depending on 
>> django.VERSION? If yes, do you think it might be worth adding a note in 
>> the documentation?
>>
>> Thank you!
>> Patrick
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/74f06398-f80e-4b4b-9be1-9c9e5db947d2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Altering migration operations depending django.Version (3rd party apps)

[Tim Graham]

makemigrations shouldn't automatically add model managers to migrations 
files. Did you opt them in with `use_in_migrations = True`? If so, I 
believe you have to drop compatibility with Django 1.7 (i.e. are you 
limited to the migrations feature set of the lowest version of Django you 
wish to support).

https://docs.djangoproject.com/en/1.8/topics/migrations/#model-managers

On Wednesday, April 22, 2015 at 8:41:34 AM UTC-4, Patrick Craston wrote:
>
> Hi Tim
>
> If I create a migration on the lowest Django version I wish to support 
> (say 1.7), it will not add the AlterModelManager operation to the 
> migration. If someone installs the app on Django 1.8, the migration will 
> run fine. 
>
> However, every time the user runs "migrate" after that it will complain 
> about the models having changes that are not reflected in a migration and 
> ask the user to run "makemigrations" which doesn't seem right?
>
> On Wednesday, 22 April 2015 13:13:40 UTC+1, Tim Graham wrote:
>>
>> The recommended way is to run makemigrations with the lowest version of 
>> Django you wish to support. As this recommendation hasn't been tested, let 
>> us know if you encounter any problems with it. A potential problem that 
>> comes to mind is if you have an EmailField which had its default max_length 
>> increased to 254 characters in 1.8. If you run makemigrations using 1.7, 
>> you won't get a migration to increase the length of that column. The best 
>> solution is probably to add an explicit max_length=254 to such fields.
>>
>>
>> https://docs.djangoproject.com/en/1.8/topics/migrations/#supporting-multiple-django-versions
>>
>> On Wednesday, April 22, 2015 at 7:32:48 AM UTC-4, Patrick Craston wrote:
>>>
>>> Hi all
>>>
>>> I'm creating a migration for a 3rd party app that needs to work with 
>>> current and previous Django versions. In Django 1.8 "makemigrations" adds a 
>>> "AlterModelManager" operation which only works with Django 1.8 and later 
>>> since AlterModelManager didn't exist before. It will also do an AlterField 
>>> to convert the IPAddressField to GenericIPAddressField.
>>>
>>> I currently have this: 
>>> https://gist.github.com/anonymous/e4d7f4f6dfd48988640d
>>>
>>> Basically I append to migrations operations if django.VERSION >= (1,8). 
>>> But as was mentioned in #django IRC, if the user applies the app's 
>>> migration in Django 1.7 those migrations don't get applied. If the user 
>>> then upgrades to Django 1.8, the user would miss those migrations?
>>>
>>> Is there a recommended way of altering migration operations depending on 
>>> django.VERSION? If yes, do you think it might be worth adding a note in 
>>> the documentation?
>>>
>>> Thank you!
>>> Patrick
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/b8607879-3c43-4a94-a18c-6828b36dc882%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pass exception to error handlers

[Tim Graham]

I have some concerns from a security standpoint. For example, some 
exception messages are definitely not meant to be displayed to end users 
and may leak server implementation details. For example:

SuspiciousFileOperation(
'The joined path ({}) is located outside of the base path '
'component ({})'.format(final_path, base_path)
)

If we proceed with the idea, maybe a separate exception attribute for a 
"user facing message" would be appropriate. Of course, if we pass the raw 
exception to the error handlers, we cannot prevent programmers from writing 
str(exception) (instead of using that custom attribute) and writing 
insecure code. As to whether that concern should block this feature, I'm 
not sure.

On Wednesday, April 22, 2015 at 7:12:53 AM UTC-4, florent...@u-dox.com 
wrote:
>
> I find this interesting too. It could be very useful when using custom 
> exception in the model.
>
> On Tuesday, April 21, 2015 at 8:58:59 PM UTC+1, Claude Paroz wrote:
>>
>> Here is some code to demonstrate a possible implementation:
>>
>> https://github.com/claudep/django/commit/5617d32e8f10861fb84bf26297dfcd4e4e40d6d7
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/25dc9714-64a6-4973-ad99-af73766becd9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: User.username max_length 254

[Micah Hausler]

I actually migrated my site to 1.7 and added a custom user model very 
easily. Here's a gist with the 
code, https://gist.github.com/micahhausler/63636f26cc87bb966218, but 
essentially all I had to do was add a new user app, copy the Django 
AbstractUser code, and set the db_table to 'auth_user'.


class User(AbstractBaseUser, PermissionsMixin):
 
objects = UserManager()
 
class Meta:
db_table = 'auth_user'



Does anyone think this method could be worth adding to the Django 
documentation? I'd be happy to open a ticket/write the docs. The only side 
effect would be that if someone were using content-types for auth_user 
objects, that would need to be migrated.
 
Micah Hausler


On Friday, February 6, 2015 at 8:10:02 PM UTC-5, Collin Anderson wrote:
>
> Hi All,
>
> I was reminded by:
> Allow shadowing of abstract fields 
> https://groups.google.com/d/msg/django-developers/6zUfnElOIks/8uwXji559EsJ
> and https://code.djangoproject.com/ticket/24288 (Custom User Models for 
> small tweaks).
>
> Could we reopen https://code.djangoproject.com/ticket/20846 and increase 
> User.username max_length to 254?
>
> Personally, that's the only thing I've ever needed to change about my User 
> class. I just need it long enough to hold email addresses. I've seen many 
> other people wanting the same thing.
>
> In 1.8 we migrated the length of EmailField from 75 to 254, so it should 
> be almost™ as easy to change the username field.
>
> If needed, we could keep the 30-character limit on UserCreationForm and 
> UserChangeForm for backwards compatibility. The limit in the database is 
> the real killer :) Though, consistency is also nice.
>
> Thanks,
> Collin
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/a845dfa4-57b7-4926-91d2-6b2e74eee651%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pass exception to error handlers

[Claude Paroz]

Le mercredi 22 avril 2015 à 07:05 -0700, Tim Graham a écrit :
> I have some concerns from a security standpoint. For example, some
> exception messages are definitely not meant to be displayed to end
> users and may leak server implementation details. For example:
> 
> SuspiciousFileOperation(
> 'The joined path ({}) is located outside of the base path '
> 'component ({})'.format(final_path, base_path)
> )

That makes sense. But as SuspiciousOperation is special-cased in
get_response, we can as well pass None in the exception parameter. It's
not the typical situation where we want the user to receive a specific
message.

> If we proceed with the idea, maybe a separate exception attribute for
> a "user facing message" would be appropriate. Of course, if we pass
> the raw exception to the error handlers, we cannot prevent programmers
> from writing str(exception) (instead of using that custom attribute)
> and writing insecure code. As to whether that concern should block
> this feature, I'm not sure.

If we exclude 400 errors (500 errors are already excluded in my patch),
that leaves 403/404 codes where we should be safe with regard to error
messages. And then, Django will not print anything by default, the user
still has to provide a custom template containing the `expression`
context variable.

Claude

> On Wednesday, April 22, 2015 at 7:12:53 AM UTC-4, florent...@u-dox.com
> wrote:
> I find this interesting too. It could be very useful when
> using custom exception in the model.
> 
> On Tuesday, April 21, 2015 at 8:58:59 PM UTC+1, Claude Paroz
> wrote:
> Here is some code to demonstrate a possible
> implementation:
> 
> https://github.com/claudep/django/commit/5617d32e8f10861fb84bf26297dfcd4e4e40d6d7


-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/1429719297.6554.18.camel%40doulos.
For more options, visit https://groups.google.com/d/optout.

Re: Pass exception to error handlers

[Tom Evans]

On Wed, Apr 22, 2015 at 3:05 PM, Tim Graham  wrote:
> I have some concerns from a security standpoint. For example, some exception
> messages are definitely not meant to be displayed to end users and may leak
> server implementation details. For example:

This is saying you can't have a gun because you might shoot yourself
in the foot, but then how do you shoot the bear?

The error handler is under the developers control, so what they choose
to do with the exception is their business. The default implementation
need not show anything more than is currently available, but it could
be replaced with something that does what the developer needs, and it
would be their responsibility that they keep their toes, so to speak.

Cheers

Tom

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/CAFHbX1J-uiNoP9OuHqX3ekPj77k%3DmbEbWsevRnakmYevBQu5EQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request for help: building a docker/vagrant platform for running Django's test suite

[Micah Hausler]

I've had a bit of experience with Docker and docker-compose (formerly fig), 
as I wrote the RST docs for docker-py, then reformatted them to MD. 
(https://github.com/docker/docker-py/commits?author=micahhausler)

I also wrote a container transformation library for converting 
docker-compose files to AWS ECS task.json 
files. https://github.com/ambitioninc/container-transform

I think docker-compose could be a great fit for this, I'd be happy to help 
out.

-Micah Hausler


On Friday, April 17, 2015 at 7:27:17 PM UTC-4, Tim Graham wrote:
>
> In 2012, Julien Phalip started the djangocore-box project [1]: "A virtual 
> machine for running the Django core test suite with every supported version 
> of Python, every supported database backend and other dependencies." 
> Unfortunately, the project hasn't seen an update in a year and a half, and 
> I think we should take a different approach than the current one of chef & 
> vagrant to reflect today's best practices.
>
> We have some private Ansible playbooks for bootstrapping the Jenkins 
> continuous integration servers, and I believe these could be adapted for 
> use with Vagrant, Docker, or something else (let's discuss the best 
> solution; I'm not an expert) to create a successor to djangocore-box. I 
> would like a knowledgeable person who has time and interest to take the 
> lead on this and I could work with you based on my experience with Jenkins. 
> Feedback welcome!
>
> [1] https://github.com/jphalip/djangocore-box
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/3143f97f-70bc-48e8-86a6-aa5787a01f3c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Writing some tests for new feature

[ST LEON]

I want to contribute one new feature to Django (doing this first time).

I reading this  and 
have one question.

First, write tests. I want to improve work of ping_google() 

 and 
add some new behavior. 

But I can't find any tests that cover this function. 

I think, that it might be here 
, but I 
can't find tests for *ping_google()*.

So, what should I do? That test needs me to see, how they works, change 
some of them and write new ones.

My changes aren't be so serious: just a very simple 2-3 new lines.

Please, help. 

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/474b740a-adb2-4c72-b297-e91941bc3e63%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Request for help: building a docker/vagrant platform for running Django's test suite

[Kevin Glavin]

Thank you everyone for your interest. I spoke with Tim last night to start 
piecing together the strategy. The gameplan on my end is to start a repo that 
we can all work from and (in)formally define the high level strategy. I'll 
enter any work items as issues on the github repo and share the link once I 
have it configured. I will seed the repo with a container or two for examples 
of what we're trying to accomplish and we can work together from there.



—
Sent from Mailbox

On Wed, Apr 22, 2015 at 12:46 PM, Micah Hausler
 wrote:

> I've had a bit of experience with Docker and docker-compose (formerly fig), 
> as I wrote the RST docs for docker-py, then reformatted them to MD. 
> (https://github.com/docker/docker-py/commits?author=micahhausler)
> I also wrote a container transformation library for converting 
> docker-compose files to AWS ECS task.json 
> files. https://github.com/ambitioninc/container-transform
> I think docker-compose could be a great fit for this, I'd be happy to help 
> out.
> -Micah Hausler
> On Friday, April 17, 2015 at 7:27:17 PM UTC-4, Tim Graham wrote:
>>
>> In 2012, Julien Phalip started the djangocore-box project [1]: "A virtual 
>> machine for running the Django core test suite with every supported version 
>> of Python, every supported database backend and other dependencies." 
>> Unfortunately, the project hasn't seen an update in a year and a half, and 
>> I think we should take a different approach than the current one of chef & 
>> vagrant to reflect today's best practices.
>>
>> We have some private Ansible playbooks for bootstrapping the Jenkins 
>> continuous integration servers, and I believe these could be adapted for 
>> use with Vagrant, Docker, or something else (let's discuss the best 
>> solution; I'm not an expert) to create a successor to djangocore-box. I 
>> would like a knowledgeable person who has time and interest to take the 
>> lead on this and I could work with you based on my experience with Jenkins. 
>> Feedback welcome!
>>
>> [1] https://github.com/jphalip/djangocore-box
>>
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "Django developers  (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/django-developers/i-feBe7eDiA/unsubscribe.
> To unsubscribe from this group and all its topics, 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/3143f97f-70bc-48e8-86a6-aa5787a01f3c%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/1429721706729.52220c23%40Nodemailer.
For more options, visit https://groups.google.com/d/optout.

Re: Writing some tests for new feature

[Marc Tamlyn]

It's quite possible this is an area which is untested - partly because when
it was originally written we didn't have the mock library to prevent the
external url call. Adding tests would be wonderful.

Marc

On 22 April 2015 at 17:29, ST LEON  wrote:

> I want to contribute one new feature to Django (doing this first time).
>
> I reading this  and
> have one question.
>
> First, write tests. I want to improve work of ping_google()
> 
>  and
> add some new behavior.
>
> But I can't find any tests that cover this function.
>
> I think, that it might be here
> , but
> I can't find tests for *ping_google()*.
>
> So, what should I do? That test needs me to see, how they works, change
> some of them and write new ones.
>
> My changes aren't be so serious: just a very simple 2-3 new lines.
>
> Please, help.
>
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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/474b740a-adb2-4c72-b297-e91941bc3e63%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/CAMwjO1FHEp5s82afzhNRqxtnJJJfidTutxHM9TOWTgQLeaQ6Ag%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Writing some tests for new feature

[Tim Graham]

I'll copy my reply from your django-users thread in case you didn't see it:

There was some recent work done on allowing customizing the ping_google 
sitemap URL, but it wasn't completed: 
https://github.com/django/django/pull/3528

You could take inspiration from your tests from there.

On Wednesday, April 22, 2015 at 2:02:27 PM UTC-4, Marc Tamlyn wrote:
>
> It's quite possible this is an area which is untested - partly because 
> when it was originally written we didn't have the mock library to prevent 
> the external url call. Adding tests would be wonderful.
>
> Marc
>
> On 22 April 2015 at 17:29, ST LEON > 
> wrote:
>
>> I want to contribute one new feature to Django (doing this first time).
>>
>> I reading this 
>>  and have one 
>> question.
>>
>> First, write tests. I want to improve work of ping_google() 
>> 
>>  and 
>> add some new behavior. 
>>
>> But I can't find any tests that cover this function. 
>>
>> I think, that it might be here 
>> , but 
>> I can't find tests for *ping_google()*.
>>
>> So, what should I do? That test needs me to see, how they works, change 
>> some of them and write new ones.
>>
>> My changes aren't be so serious: just a very simple 2-3 new lines.
>>
>> Please, help. 
>>
>> Thanks!
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers (Contributions to Django itself)" 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.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/django-developers/474b740a-adb2-4c72-b297-e91941bc3e63%40googlegroups.com
>>  
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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/50d2f680-d1a7-4212-9b7f-47fe1b662127%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.