from:"Baptiste Mispelon"

Re: Unable to run tests with git bisect run

2016-12-01 Thread Baptiste Mispelon

Hi,

You need to put the `PYTHONPATH=...` thing at the beginning of the line,
like so:

PYTHONPATH=..:$PYTHONPATH git bisect run ./runtests.py flattened-prefetch

Baptiste

On 12/01/2016 04:46 PM, Vimarsh Chaturvedi wrote:

Hey folks,

This is the first time I'm trying to contribute to Django. I am
working on ticket #27554 .
In the comments, there was a link posted to "Bisecting the exact
commit that introduced the regression
"
saying that it could be helpful. So I started going about it.

The problem is when I was running the test suite for the first time
the online docs said to run "./runtests.py" from inside the tests
directory which didn't work out for me but the README inside the tests
directory said to run

"PYTHONPATH=..:$PYTHONPATH ./runtests.py" which ran the tests.

So once I started bisecting every time I was going back I was running
"PYTHONPATH=..:$PYTHONPATH ./runtests.py flattened-prefetch".
flattened-prefetch being the name of the directory where I've written
my tests. Once I reached where a commit where all tests were passing I
tried running
"git bisect run PYTHONPATH=..:$PYTHONPATH ./runtests.py
flattened-prefetch" and it's giving me the following error:

"running PYTHONPATH=../ tests/runtests.py flattened-prefetch
/usr/local/Cellar/git/2.4.6/libexec/git-core/git-bisect: line 440:
PYTHONPATH=../: No such file or directory"

yet it's still saying "bisect run success". Since it didn't find
PYTHONPATH so I'm guessing it's wrong?

Thanks

Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/7785957f-927a-4c1f-a253-3d783468170d%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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/0debecfe-76dc-7bd8-c407-50cf01e102b8%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Consider reverting or adding guidelines on how to use class based views for security sensitive features

2016-11-22 Thread Baptiste Mispelon

Hi Markus,

Thanks for your clear description and for bringing this up for discussion.

I don't agree with your conclusions though.

1) Keeping around two implementations of auth views seems
counter-productive to me in terms of security because it effectively
doubles the potential for bugs or security issues (not to mention the
added maintenance work). We should have only one set of auth views.

2) Our users want more extension hooks for auth views. If we don't
provide them, some users will end up copy/pasting Django's views and
tweak what they need (I have done that myself more than once). This
copy/pasted code then won't receive updates (potentially
security-related) when Django changes, which also presents a danger to
our users (unless they track changes in the code, which is unlikely).

3) Your description of the security issues seems quite alarming but how
does it compare with others in the past? To me, a 4-month window
actually seems quite small, not to mention that the issue never even
made it to a release.

4) I agree with Tim that there's an issue in our test suite.
Function-based views give you the assumption that all HTTP methods will
use the same entry point into your view. You lose this assumption with
class-based views but I don't view this as a defect: to me, this is one
of the big advantages of class-based views. This probably means that we
should audit Django's code and add tests to make sure we cover all
supported HTTP methods.

Thanks,
Baptiste

On 11/21/2016 08:11 PM, Markus Holtermann wrote:

Hi all,

As it turned out [1], due to their complexity, using class-based
generic views for security-sensitive functionality can result in
unintended behavior. Essentially, the reset token was only checked on
GET requests, not on POST. This was due to the check being in
`get_context_data()` (which is only called on GET but not POST except
for invalid forms) and not higher up the stack. Validation could
happen in the SetPasswordForm but doesn't really belong there either.
The form is being used by the admin to allow superusers to change
other users' password. Also, password resets could probably happen via
other ways that want to leverage a form that doesn't require a token.
In the end, from my perspective the check for the correct token does
belong in the view.

While the reported issue was fixed [2] it raises the question if the
added functionality of class-based generic views is worth the danger
of shooting ourselves in the foot. I see the benefits of GCBVs. But
given that the reported issue stayed unnoticed for 4 months makes me
think that those views are not the best for these use cases and easily
underpin the security functionality. Hence I suggest to revert the
patch (including all additional features they gained) unless they are
integrated in the function-based views and add guidelines on how to
use class-based generic views for security sensitive feature.

This is thethread to get the discussion about this started.

One thing I want to suggest regardless if the class-based generic
views are removed again or not, is to hold off the deprecation of the
function-based views. This allows users who feel the same to not use
class-based generic views without having deprecation warnings. At
least until the next LTS release.

Furthermore, myself and Florian Apolloner, who discovered the issue,
are leaning +0 to +1 on the revert of the class-based views.

Cheers,

Markus Holtermann

[1]
https://www.djangoproject.com/weblog/2016/nov/21/passwordresetconfirmview-security-advisory/

[2] https://github.com/django/django/pull/7591
--
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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/19b675f5-c25a-43e8-ac73-2a31b9e351d6%40googlegroups.com
.

For more options, visit https://groups.google.com/d/optout.

Re: Can you remove a model's last field of SQLite3 in Django 1.8?

2015-11-29 Thread Baptiste Mispelon

Hi,

I believe the issue you're describing has already been reported:
https://code.djangoproject.com/ticket/24424

This ticket is still open and there is a long discussion on it (30
comments).

Baptiste

On 11/29/2015 06:15 PM, KwangYoun Jung wrote:

Can you remove a model's last field of SQLite3 in Django 1.8?

I have a model that has only one column in SQLite3.
When I remove a last field of the model, I get an error like below

*django.db.utils.OperationalError: near ")": syntax error

*Anyone knows about this issue ?
--
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
.

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/565B347F.5030606%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: User notification by email of account detail changes

2015-11-15 Thread Baptiste Mispelon


I don't think it's documented anywhere.

I found the link by going to https://www.djangoproject.com/~bmispelon/ 
(replace by your username) and there was a link to it in the right side bar.




Baptiste

On 11/15/2015 02:57 PM, Daniele Procida wrote:

On Sun, Nov 15, 2015, Baptiste Mispelon  wrote:


For your djangoproject account, you can change your display name and
email there: https://www.djangoproject.com/accounts/edit/.

Heh, thanks, not even Florian was aware of that.

Is this documented somewhere?

Daniele



--
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/56489500.3010709%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: User notification by email of account detail changes

2015-11-15 Thread Baptiste Mispelon

For your djangoproject account, you can change your display name and 
email there: https://www.djangoproject.com/accounts/edit/.




Baptiste

On 11/15/2015 02:46 PM, Daniele Procida wrote:

I've been discussing with Florian on IRC a suggestion for improved account 
security.

On many sites, you will get a message a message like this:


Hello evildmp,

We wanted to let you know that your GitHub password was changed.

If you did not perform this action, you can recover access by entering
dani...@vurt.org into the form at https://github.com/password_reset.

To see this and other security events for your account, visit https://
github.com/settings/security.

If you run into problems, please contact support by visiting https://
github.com/contact or replying to this email.

(In fact my gumtree.com account was compromised, and this mechanism is how I 
learned about it, and was able to alert Gumtree and have a fraudulent 
advertisment removed from my account within minutes).

A similar thing would be valuable in Django, to help improve the security of 
all Django accounts and sites.

I am not sure how it could or should be implemented; Florian suggests as part 
of a more general audit framework.

On a related matter, my djangoproject.com account has an associated email 
address (not the same one as at code.djangoproject.com) but I don't think I am 
able to change that.

Daniele



--
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/56488EB1.3020306%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Renaming the postgresql_psycopg2 backend

2015-07-26 Thread Baptiste Mispelon

I finally got around to creating a ticket for this:
https://code.djangoproject.com/ticket/25175

On 07/15/2015 03:30 PM, Collin Anderson wrote:
We definitely should make sure postgresql_psycopg2 still works as
expected. As a data point, Heroku uses "postgres" instead of
"postgresql" in their DATABASE_URL scheme. Maybe we could support all
three? :)

On Wednesday, July 15, 2015 at 9:17:30 AM UTC-4, Baptiste Mispelon wrote:

Hi everyone,

After starting a new project recently and failing three times to type
the name of the postgres backend correctly, I was wondering if
there's
really any value in keeping around this strange name.

From what I understand, it's a historical artifact from a time when
there was more than one postgres backend.

Could we at least make it an alias of a more simply named
"postgresql"
backend?

Thanks,
Baptiste

--
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
<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/3ab4f912-fc25-4859-bd8d-5651e2c68e93%40googlegroups.com
<https://groups.google.com/d/msgid/django-developers/3ab4f912-fc25-4859-bd8d-5651e2c68e93%40googlegroups.com?utm_medium=email&utm_source=footer>.

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/55B49865.9050408%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Renaming the postgresql_psycopg2 backend

2015-07-15 Thread Baptiste Mispelon


Hi everyone,

After starting a new project recently and failing three times to type 
the name of the postgres backend correctly, I was wondering if there's 
really any value in keeping around this strange name.


From what I understand, it's a historical artifact from a time when 
there was more than one postgres backend.



Could we at least make it an alias of a more simply named "postgresql" 
backend?



Thanks,
Baptiste

--
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/55A65D4F.1020704%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

2014-12-17 Thread Baptiste Mispelon


Hi Torsten,

As far as I know, it's not often that people get kicked out of this 
mailing list (note that Christian was kicked out, not banned, so he can 
join back if he'd like) so I'm not sure what's "customary".


However, we strive to create a friendly and inclusive community here, so 
toxic and insulting behavior is not simply ignored.


In this instance, I think Daniele's response was appropriate and I stand 
by it too.


I hope that answers your question.

Cheers,
Baptiste

PS: The mailing list is publicly viewable at 
https://groups.google.com/forum/#!forum/django-developers. It's only for 
posting here that you need to be registered.


On 12/17/2014 11:29 AM, Torsten Bronger wrote:

Hallöchen!

Daniele Procida writes:


[...]

In the meantime I have removed you from our email lists, since
your tone is not welcome here. Please don't come back unless you
can communicate in a more acceptable way.

Is this customary procedure on this mailing list in such cases?
Normally one simply ignores postings/authors one doesn't like.  I
hope that banned users don't have the answers to my questions.  ;-)
Besides, a sock puppet is made in minutes ...

Tschö,
Torsten.



--
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/54916546.6080201%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: ANN: Django website redesign launched

2014-12-17 Thread Baptiste Mispelon

Hi Jorge,

First off, thank you for your feedback, it's very much appreciated.

Regarding your question about Trac, the differences in UI that you list
are definitely not intended.

Ola Sitarska and me did some work to try and adapt the new design to
Trac but it's proven to be difficult.

Could you please file some issues at
https://github.com/django/code.djangoproject.com/issues (this is the
repository of our Trac instance)?

If you'd like to try your hand at fixing those issues, I'd be happy to
get you started on installing Trac locally. You can get in touch with my
by email or on IRC (#django-websites on Freenode).

Have a nice day,
Baptiste

On 12/17/2014 11:28 AM, Jorge C. Leitão wrote:

Dear Django community,

I would like to congratulate you very much for this. I'm very pleased
to see that the work in Django is much better presented to the world,
which I think we all agree is an important component of the project.

Generally speaking, I like very much the overall look and feel of the
website. I imagine it is very hard to agree on them, specially since
it is a component that has some intrinsic subjectivity.

I have a question regarding the layout:

In the previous website there was a noticeable difference between the
website UI and the UI of the issue tracker. Are we aiming to keep that
difference or do we aim to make them indistinguishable?

This is because it seems that some elements of the tracker were
changed to blend with the new look, but others don't. Specifically:

- In the main content of the issue tracker the horizontal lines have a
shadow in the bottom; The other sections don't.
- In the issue tracker, some content is boxed (e.g. wiki), while other
doesn't (new ticket), and the boxes are corner-rounded (while the
website has rounded elements besides buttons).
- In the wiki of the issue tracker, the font seems to be "blurred"(?),
compare with sidebar.

I would prefer the same look of the issue tracker for consistency, but
since that section of the website is aimed to developers of Django,
there can be a rational to make it different. Could we clarify this so
we know what is a bug to report and what is an intended feature?

In any case, the quality of Django website conveys now much better the
quality of the Django project. Thank you for that.

Cheers,
Jorge

On Tuesday, December 16, 2014 5:09:55 PM UTC+1, Jannis Leidel wrote:

Hi everyone,

We're incredibly proud to share with you the new design of the
Django website, the documentation and the issue tracker.

This is a long time coming and we couldn't be happier to finally
ship it :)

As you can imagine, there will be bugs, so please bear with us and
report issues to the issue tracker at
https://github.com/django/djangoproject.com/issues

More infos about the redesign and its history can be found in the
blog post:

https://www.djangoproject.com/weblog/2014/dec/15/announcing-django-website-redesign/

Happy coding, everyone!

Jannis

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/54916181.7060209%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: I have an issue which is fixed in master but not in stable/1.7.x

2014-12-01 Thread Baptiste Mispelon

Hi Yann,

The policy we use for backporting is described there:
https://docs.djangoproject.com/en/1.7/internals/release-process/#supported-versions

> The rule of thumb is that fixes will be backported to the last major
release for bugs that would have prevented a release in the first place
(release blockers).

The issue in question (https://code.djangoproject.com/ticket/13776)
doesn't meet those criteria (it's not a regression so it wouldn't be
categorized as a release blocker).

This leaves you with the following options:

* Wait until 1.8 is released with this fix (and use a workaround or a
private fork until then)
* Find a good argument as to why this particular fix should be
backported ("all the tests pass" is a good start but it's not enough).

I hope that makes sense.
Thanks,

Baptiste

On 12/01/2014 03:49 PM, Yann Fouillat wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

I have an issue which is corrected in master but not in the 1.7.x
branch and I would like to know what I should do ?

The commit fixing my issue is
https://github.com/django/django/commit/45e049937d2564d11035827ca9a9221b86215e45#diff-70af885c2725fe87eb3b99a393268d10.

I tried to backport it in stable/1.7.x and all the tests pass.

Regards,
- --
Yann FOUILLAT

Ingénieur Développeur
Makina Corpus
Tél : 02 51 79 80 82
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJUfH/mAAoJEO1YhKM5jgEdTV4IAJSE+IftGMPRxZEaXCYQguGV
NxdOZIDizqXOFWc4zwwS44eZoXcZyTjUKw/zs/DSHQ/CHd0yYTkOD1mkdoEtPVvE
V3xjh3bMPodB95qwxSpLn11//far02J9pob3XNj0G7pdMN7wqmICNNvE6Cpa/Prj
6vp5HN0NYwYhLiFowC8iMpt4b2KWiXba1YPNf1UmuGI5tNa5jTuc4oJx+r1pMxID
fAE4UdX4oWyqMzHBIJ/LWa5SqtrGY9/gcHlGI2zIDNSxIEubva0UAfKp2AKPnKwL
vjyKMbdofmxDNw0v4AgvBS/nslF0vvFwz93BswxjTJa8SQbF0rVHxMzK/DdyDrs=
=Wjs+
-END PGP SIGNATURE-

--
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/547C857C.8030301%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Updating the organization of the Django Project

2014-07-28 Thread Baptiste Mispelon

Another big +1 from me.

Thanks for yet another awesome refactor,

Baptiste

On 07/27/2014 03:52 PM, Honza Král wrote:

Thanks for pushing for this!

On Jul 25, 2014 5:22 PM, "Jacob Kaplan-Moss" > wrote:

+1.

Aymeric, I can't thank you enough for taking this on and running
with it.

Jacob

On Fri, Jul 25, 2014 at 7:20 AM, Chris Foresman
mailto:fores...@gmail.com>> wrote:

As a non-core community member, I welcome a streamlined way
for new potential coders to contribute.

On Thursday, July 24, 2014 7:02:16 AM UTC-5, Russell
Keith-Magee wrote:

Hi Aymeric.

A big +1 from me. Thanks for all your work drafting these
modifications.

Russ %-)

On Wed, Jul 23, 2014 at 9:29 PM, Aymeric Augustin
wrote:

Hello,

I’ve been working on updating our organization:
https://github.com/django/django/pull/2947

This proposal attempts to address several issues with
our current organization. There’s no short version and
any simplistic interpretation will be wrong. Here are
the main factors at play.

1) In theory, the core team is the group of
committers, each of whom has been judged capable of
making code design decisions. (Astute readers will
have noticed that it isn’t true in practice.) This
restrictive approach to staffing makes it hard to
cover all of our HR needs. Specifically:
a) It creates a chasm between non-core and
core contributors, which has perverse side effects and
creates tons of frustration.
b) It drives away would-be contributors whose
help wouldn’t involve committing code to the main
Django repository.
c) Even if such contributors are found, it’s
hard to convince the core team to bring them on board.

2) Since the BDFLs have stepped down, there’s no
obvious way to counteract honest mistakes made by core
developers. This is making the core team uncomfortable
at times. While BDFLs hardly ever had to intervene,
their mere existence played a role. We need to
recreate that role in a more democratic fashion.

3) We’re good at burning out our most prolific
contributors. Since we lack structure, it’s too easy
to become responsible for everything, until you can’t
handle it anymore and throw the towel. We must
classify roles, write down who takes what role, fill
the gaps with new volunteers, and remove pressure
around stepping down.

4) As we have grown, having no explicit organization
within the core team makes it complicated for
newcomers to figure who does what and how they fit in
the picture. It doesn’t erase the power structure. It
merely hides it.

My proposal builds upon years of discussions at
DjangoCons. It has gone through many rounds of
feedback inside the core team already. It’s an
evolution, not a revolution. It takes into account the
growth of the project, acknowledges and formalizes
some things that we’re already doing, and introduces
just enough formal organization to make everyone
comfortable.

It doesn’t encompass everything we could do to improve
our organization. In particular I expect some follow
up work on how we manage roles in order to avoid burnout.

I would like to ask the core team for a formal vote on
this pull request, according to our guidelines. [1]
Please vote by the end of July in UTC
(2014-08-01T00:00:00Z).

Obviously, I’m voting +1.

Thank you,

--
Aymeric.

[1]

https://docs.djangoproject.com/en/stable/internals/contributing/bugs-and-features/#how-we-make-decisions

--
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
.

Re: error in "makemessages" command on latest django version (1.8dev)

2014-04-30 Thread Baptiste Mispelon

Hi,

No need for apologies: your message is completely appropriate for this
mailing list.

I can reproduce the issue you're describing and it does look like a bug.
It seems to have been introduced by this commit:
https://github.com/django/django/commit/0707b824fe77e08ca8b75fcc3738ada694f2a3a6.

Would you mind opening a new ticket for this on
https://code.djangoproject.com/newticket?

Thanks!

On 05/01/2014 04:35 AM, Fabio Caritas Barrionuevo da Luz wrote:

Hello sorry if this is not the correct place for these questions
I was testing the latest version of Django[1] directly from Github and
am having this problem.

In this link you can see all the steps I did to get this error

https://asciinema.org/a/9213

I try:

python manage.py makemessages

Result in this:

*optparse.OptionConflictError: option -e/--extension: conflicting
option string(s): -e*

That would be a bug or am I doing something wrong

[1]
https://github.com/django/django/tree/8f6dff372b174e772920de6d82bd085f1a74eaf2

For more options, visit https://groups.google.com/d/optout.

--
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/5361CE75.2080707%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Wrong translation in Brazillian portuguese

2014-04-07 Thread Baptiste Mispelon

Hi,

Django's translations are managed on a separate website called transifex.
You can find more information on the translation process on our
documentation at
https://docs.djangoproject.com/en/1.6/internals/contributing/localizing/#translations.

As far as I know, the window for the 1.7 translations is still open so
if you fix the translation on transifex, it should make its way into the
final 1.7 release.

Thanks,
Baptiste

On 04/07/2014 04:45 PM, Bruno Ribeiro da Silva wrote:

Hi everyone,

I found a wrong translation in Brazillian portuguese that affects
django 1.7 and it's present in master too. I'm going to open a ticket
for this and make a pull request. Do you think it's possible to fix
for the 1.7?

Thank you!

--
Bruno Ribeiro da Silva
Python Dev and Homebrewer!
--
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
.

For more options, visit https://groups.google.com/d/optout.

--
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/5342C0CF.4000406%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [GSoC 2014 proposal]. Improving admin translation and formalizing Meta objects.

2014-03-13 Thread Baptiste Mispelon

Hi,

Regarding the translation issues, there's a lengthy discussion on
https://code.djangoproject.com/ticket/11688 which you might find
interesting.

--
Baptiste

On 03/13/2014 10:00 AM, Алексей Сидаш wrote:

How so? Can you provide a few examples -- I know that numbering
can be a problem for Russian translations, but that's hardly a
problem of the admin itself.

There are three grammatical genders in Russian, and all the words in
sentense should match gender of subject. You seem to be right about
abusing meta with this work, gettext functionality may be enough,
gettext `context` feature may help. See this question
.
We need to make some changes in templates, admin tempates to add
apropriate context for needed letters.

For example, we have two models. *Article* and *Post*.
In English we say /"Add new Article"/ and /"Add new Post"/, right?
But in Russian article's grammatical gender is "female", but post's
grammatical gender is "male", so we should say "Добавить
нов*ую* Статью" for "Add new Article" and "Добавить нов*ый *Пост" for
"Add new Post".
The suffix (bold) depends on noun's(Model name in this case)
grammatical gender.
I believe, this problem takes place not only in Russian, but,
unfortunately, I speak only Russian and English.
One of the solutions is providing *gettext_context* field in model's
Meta(or in more suitable place) and select aproppriate translation,
depending on this property using contextual markers
.

Also, I think we may add custom admin widgets for every
application, for example, we define a Meta class in
application __init__.py, where we make add property
widget_template, and add there something custom instead of
default links.

I don't see any benefit in this, you'll need to explain this in
more detail.

Do you see red line? Here, instad of simple link, some custom
information may be shown. For example, /"N new users registered in
last 24 hours"/ and staff like that.

Also, notifications in main page of admin panel may be useful, for
example: Blog application, where admins can publish posts and users
can comment them. When post, published by me is commented, Blog
application pushes new notification, and I can see an active button in
admin(Something like github notifications).

Thank you for your answer,

Best regards,

Alexey

For more options, visit https://groups.google.com/d/optout.

--
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/5321A273.1040307%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Is it a mistake on docs for django 1.5?

2014-01-20 Thread Baptiste Mispelon

Hi,

It's actually a bit trickier than that (making the example work required
some serious contortions and I wouldn't recommend it in practice).
As noted in one of the comments that I added, we can't rely on the
default implementation of get_object() because we've overridden
get_queryset() to return instances of Book, not of Publisher.

I'm not sure why I didn't backport that commit to the 1.5 branch when I
made it.

I'll do so now and the fix should appear online soon.

Thanks for catching this.

Baptiste

On 01/20/2014 10:24 PM, Leonardo Borges Avelino wrote:

Yes. It works, but the line:

model = Publisher # for SingleObjectMixin.get_object

is supressed in this commit. queryset is optional, because it calls
get_queryset method, that uses model=Publisher, and IMHO it's better
to have model=Publisher than hardcode the queryset

I think that we just need to pass self to get_object
--
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/CAMnPXq9isV9jNj8O6Fiw22mQKPcwHwAuQQnJJe8fSp_p%2B_qEeQ%40mail.gmail.com.

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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/52DD9C72.1060906%40gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Why not use @classmethod decorator consitently in django/utils/functional.py?

2013-11-20 Thread Baptiste Mispelon

Hi Adam,

Django 1.6 only supports Python 2.6 and older [1] and Django 1.7 will
support Python 2.7 onwards [2].

[1] https://docs.djangoproject.com/en/1.6/releases/1.6/#python-compatibility
[2] https://docs.djangoproject.com/en/dev/releases/1.7/#python-compatibility

Cheers,
Baptiste

On 11/20/2013 10:39 AM, Adam Smith wrote:

Hi Shai,

Just FYI, on github @charettes merge my PR replacing almost all
`meth = classmethod(meth)` with `@classmethod`.

So I assume you guys are going to drop support for python2.4 and
older, right?

Best Regards
Adam

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/1fc2612a-d127-45f6-982c-81354e7d75cd%40googlegroups.com.

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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/528C857D.6090200%40gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: version number in Django documentation URLs

2013-08-29 Thread Baptiste Mispelon


On 08/30/2013 12:10 AM, Daniele Procida wrote:

RTFD.org can use "latest" for the version number in docs - why don't we?

It would be nice to be able to refer for example to 
.

Daniele

https://docs.djangoproject.com/en/stable/internals/release-process/ 
works, but I'm not sure that it's documented anywhere.


Baptiste

--
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Django documentation: Using mixins with class-based views

2013-06-23 Thread Baptiste Mispelon


Hi,

I believe you're right, this code is incorrect.
Would you mind opening a ticket for this on 
https://code.djangoproject.com/newticket ?


Thanks,
Baptiste

On 06/23/2013 05:29 PM, Michal Slįdek wrote:

Hello!

I tried to use following examples:
https://docs.djangoproject.com/en/dev/topics/class-based-views/mixins/

import  json
from  django.http  import  HttpResponse
class  JSONResponseMixin(object):
 response_class  =  HttpResponse
 def  render_to_response(self,  context,  **response_kwargs):
 response_kwargs['content_type']  =  'application/json'
 return  self.response_class(
 self.convert_context_to_json(context),
 **response_kwargs
 )
 def  convert_context_to_json(self,  context):
 return  json.dumps(context)

from  django.views.generic.detail  import  SingleObjectTemplateResponseMixin
class  HybridDetailView(JSONResponseMixin,  SingleObjectTemplateResponseMixin,  
BaseDetailView):
 def  render_to_response(self,  context):
 # Look for a 'format=json' GET argument
 if  self.request.GET.get('format','html')  ==  'json':
 return  JSONResponseMixin.render_to_response(self,  context)
 else:
 return  SingleObjectTemplateResponseMixin.render_to_response(self, 
 context)

It seems to me, that attribute response_class = HttpResponse in 
JSONReponseMixin overlaps attribute response_class = TemplateResponse 
in TemplateResponseMixin (and SingleObjectTemplateResponseMixin) and 
breaks non-json requests.


Michal
--
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.
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.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Good practices for production settings

2013-03-17 Thread Baptiste Mispelon


Hi,

I like the patch and I think it's a welcome addition to the documentation.

I spotted one minor spelling mistake: "an hostile environment" should be 
"a hostile environment" (L5 of checklist.txt).


Good work,

Cheers,
Baptiste

--
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: Unable to run tests with git bisect run

Re: Consider reverting or adding guidelines on how to use class based views for security sensitive features

Re: Can you remove a model's last field of SQLite3 in Django 1.8?

Re: User notification by email of account detail changes

Re: User notification by email of account detail changes

Re: Renaming the postgresql_psycopg2 backend

Renaming the postgresql_psycopg2 backend

Re: ANN: Django website redesign launched

Re: ANN: Django website redesign launched

Re: I have an issue which is fixed in master but not in stable/1.7.x

Re: Updating the organization of the Django Project

Re: error in "makemessages" command on latest django version (1.8dev)

Re: Wrong translation in Brazillian portuguese

Re: [GSoC 2014 proposal]. Improving admin translation and formalizing Meta objects.

Re: Is it a mistake on docs for django 1.5?

Re: Why not use @classmethod decorator consitently in django/utils/functional.py?

Re: version number in Django documentation URLs

Re: Django documentation: Using mixins with class-based views

Re: Good practices for production settings

19 matches

Site Navigation

Mail list logo

Footer information