Re: Student Proposal for Google Summer of Code 2012
On 5 February 2012 20:16, j4nu5 wrote: > Hi, > > Google Summer of Code 2012 has been announced. > http://google-opensource.blogspot.com/2012/02/google-summer-of-code-2012-is-on.html > > I want to work on extending Django's database migration capabilities, > as a student. > > Database migrations have always been a pain in Django and most people > rely on third party apps like South or Nashvegas for migrations. I > feel migration capabilities should be made part of the main codebase. > > Specifically, adding a new field to an existing model and issuing > 'manage.py syncdb' has no effect since manage.py does not issue ALTER > TABLE commands. Adding such functionality might be difficult to > implement but will be a boon to new users (especially those migrating > from Rails who are used to out of the box migration support). > > Is this project worthy of being taken up for this year's Summer of > Code? Disclaimer: I'm not in any way involved with Django's GSoC participation. A schema alteration API was one of the accepted projects last year, which unfortunately, was not successfully completed[1]. So I'd say it's definitely worthy. Might be worth having a look at the code that was completed in last year's attempt to see if it is worth including in your proposal. Last year's ideas are here [2], and if that page's history is any indication, this year's ideas should be up fairly soon. [1] http://groups.google.com/group/django-developers/browse_thread/thread/a52202349049472f [2] https://code.djangoproject.com/wiki/SummerOfCode2011 > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: #14633 - organization of settings docs
Looks good. Adds a bit more structure for browsing but doesn't significantly change how the page is used, which is probably through CTRL-F. As mentioned by others in the issue, the distinction current and deprecated settings seems very arbitrary. I think it'll be better to sort the deprecated settings like any other setting, but include a better visual distinction to indicate that they're deprecated (at least bold the word deprecated I think). When someone's looking for a setting, they're not thinking about whether or not a setting is deprecated; they're probably looking for what it means and how it can be configured. On 8 January 2013 08:02, Tim Graham wrote: > I'd appreciate feedback on #14633 - "Organize settings reference docs". So > far I've broken out the settings for each contrib app into their own > sections. The one comment on the pull request suggests further breaking up > the settings listed in the "Core settings" section, e.g. logging, caches, > globalization (i18n/l10n), email, file uploads/media, storages, and > security. I don't feel strongly about this proposal: it could be useful, but > it could also be ambiguous as to which section a particular settings belongs > in. > > The pull request also suggests organizing the default settings.py in a > similar fashion. While it may be outside of the scope of this ticket, it > could be worthwhile to discuss that suggestion as well. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/django-developers/-/Uku6Vo8oCvIJ. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
making URL resolving/reversing gradually more flexible
[First timer participating in the Django dev process, so apologies if
I have missed some protocol etc.]
First up, this is not about adding an alternate URL
resolution/reversal method to the core; I've noticed a fair bit of
resistance to that.
PROBLEM:
I want to make my website available via an API with URLs like this -
http://example.com/newitems/ => returns HTML
http://example.com/newitems.xml => returns XML
http://example.com/newitems.json => returns JSON.
To represent this in urls.py, I have to either:
a) write a separate url entry for each one
b) write 2 url entries, one for newitems/ and another for
newitems\.(?P\w+). This is the better option, but still
annoying. Plus it forces my view to validate whether or not the format
value is acceptable (e.g. is either xml or json).
I have to do this for every URL I wish to make available via an API,
bloating out my urls.py file. (I'm aware I can use the HTTP-ACCEPT
header instead, but there is a need to be able to force the response
format in the URL for certain uses.)
MY DESIRED SOLUTION:
Subclass RegexURLPattern, and override the resolve method so that it
will replace a placeholder, e.g. (?#format), with the appropriate
regexps (/|\.xml|\.json). Effectively it will perform something
similar to this regexp instead -
^newitems(/|(?P(\.xml|\.json))) where the list of accepted
formats will be defined in settings. This subclass will be returned
using an alternate url(...) call, e.g. murl(...).
So my urls.py will look like -
urlpatterns = patterns('project.app.views',
murl(r'^/(?P\d+)(?#format)$', AppView.as_view(),
name='app_view1'),
)
(For completeness, the view is a CBV, and uses the format arg to
determine which template to render, and using what MIME type to
respond.)
This is a proven way of extending the URL system, as demonstrated by
the various projects out there for alternative URL specification
syntaxes, e.g. django-easyurls.
ROADBLOCK:
The issue with this solution is that while resolving will work fine,
reversing will not. The list of possible URLs for a particular view is
determined by _populate in RegexURLResolver, and is based on the
regexp pattern alone. Django doesn't support | in regexps
(understandably), and there is no way to supplant this with additional
regexps or possibilities at the moment, even though the infrastructure
is there during reversal.
RESOLUTION - PHASE 1:
Because of the friction and work required to fully revamp the URL
resolution system, this phase is a short, simple fix that will suffice
for most cases where people want to extend the URL resolution system.
Refactor out line 218 (in trunk) in django/core/urlresolvers.py:
bits = normalize(p_pattern)
... into a separate method in RegexURLPattern:
def get_possibilities(self):
return normalize(self.regex.pattern)
... and replace line 218 in django/core/urlresolvers.py with:
bits = pattern.get_possibilities()
That's it. I'll create a patch for this later if the consensus is
positive. The above change allows subclassed RegexURLPattern classes
to alter what is returned as possible URLs from that pattern. I'm
hoping this simple change can be made in Django 1.3.
Of course, the possibilities returned still have to be regexps, which
leads to phase 2...
RESOLUTION - PHASE 2:
The ultimate goal should be a URL resolution system that allows
alternate URL spec syntaxes to be first-class citizens, allowing
regexp based URL specs and say, URI Template specs to exist
side-by-side.
My plan would be to create an abstract base class for all URLPatterns,
which RegexURLPattern will extend. The existing behaviour will mostly
stay, except the get_possibilities from phase 1 will be deprecated in
favour of a new reverse method. The reverse method will be called by
the new universal URLResolver class for matches when reversing URLs,
and if a match exists, that will be returned. During _populate(), the
new universal URLResolver class will group URLPattern objects by view
callback and name, instead of the output of
get_possibilities/normalize.
This approach requires no changes to existing urls.py; in fact, from a
dev perspective, they would only notice the difference if they choose
to use alternate URL spec syntaxes. The existing regexp system will
work as it has always worked. And it makes sense that the URLPattern
object is responsible for resolving and reversing itself, and not the
resolver.
Until this phase is reached, the API should be considered private so
devs are on notice that things will change and may break existing
custom URL resolution code.
Again, I'm happy to have a crack at making this work if the consensus
is positive.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/dja
Re: making URL resolving/reversing gradually more flexible
On 12 November 2010 19:14, burc...@gmail.com wrote:
> Ah, sorry, tl;dr happened to me in previous message.
>
> I used to do the following:
>
> alternatives = {'html': '/', 'xml': '.xml', 'json': '.json'}
> for name, alt in alternatives.iteritems():
> urlpatterns += ('^newitems'+alt+'$', 'views.newitems', {'format':
> name}, 'newitems-'+name)
Then you're cluttering urls.py through code. You need to repeat that
for every API-enabled URL.
> You can make your own method that will do this.
> Anyway, only your code can know how to select one of the suggested
> alternatives for reverse, so your suggested approach has no
> advantages.
... and that's the point. It is the pattern's job to suggest
alternatives, not the resolver's.
>>This approach requires no changes to existing urls.py
> But you have to update all django 3rd party libraries to realize every
> url pattern they use can have get_possibilities !
How many third-party libraries out there use custom URL pattern
classes, ones that don't subclass from RegexURLPattern?
I doubt there are many. But to cater for this fact, the resolver can
simply check for the existence of get_possibilities, and if it isn't
there, revert to the existing behaviour. For example,
if hasattr(pattern, 'get_possibilities'):
bits = pattern.get_possibilities()
else:
bits = normalize(p_pattern)
> And you now can't pass secondary pattern into django libs that are not
> aware of your feature.
Not sure what you're talking about here. I can't see how my changes
will break anything, unless a library is using a URLPattern that
doesn't extend RegexURLPattern. And again, as above, a small fix can
solve that.
Just so I'm clear, this is a *backwards-compatible* change. Nothing
should break if the above change is incorporated into the original
proposal.
> So, many-to-many relation between urlpatterns entry and view name only
> complicates things.
I am not suggesting a many-to-many relationship between urlpatterns
and view names. Each urlpattern can still only match 1 view name. It
is a many-to-one relationship. Not that this case already exists if
you use ? in a regexp in a URL pattern.
> On Fri, Nov 12, 2010 at 1:56 PM, burc...@gmail.com wrote:
>> Hi Sam,
>>
>> what's the problem with regexp = '^newitems'+SUFFIX+'$' where
>> SUFFIX='(/|\.xml|\.json)' ?
>>
>> And if you need more shortcuts, there are surlex (
>> http://codysoyland.com/2009/sep/6/introduction-surlex/ ) and
>> alternatives.
>>
>> On Fri, Nov 12, 2010 at 11:25 AM, Sam Lai wrote:
>>> [First timer participating in the Django dev process, so apologies if
>>> I have missed some protocol etc.]
>>>
>>> First up, this is not about adding an alternate URL
>>> resolution/reversal method to the core; I've noticed a fair bit of
>>> resistance to that.
>>>
>>> PROBLEM:
>>> I want to make my website available via an API with URLs like this -
>>> http://example.com/newitems/ => returns HTML
>>> http://example.com/newitems.xml => returns XML
>>> http://example.com/newitems.json => returns JSON.
>>>
>>> To represent this in urls.py, I have to either:
>>> a) write a separate url entry for each one
>>> b) write 2 url entries, one for newitems/ and another for
>>> newitems\.(?P\w+). This is the better option, but still
>>> annoying. Plus it forces my view to validate whether or not the format
>>> value is acceptable (e.g. is either xml or json).
>>>
>>> I have to do this for every URL I wish to make available via an API,
>>> bloating out my urls.py file. (I'm aware I can use the HTTP-ACCEPT
>>> header instead, but there is a need to be able to force the response
>>> format in the URL for certain uses.)
>>>
>>> MY DESIRED SOLUTION:
>>> Subclass RegexURLPattern, and override the resolve method so that it
>>> will replace a placeholder, e.g. (?#format), with the appropriate
>>> regexps (/|\.xml|\.json). Effectively it will perform something
>>> similar to this regexp instead -
>>> ^newitems(/|(?P(\.xml|\.json))) where the list of accepted
>>> formats will be defined in settings. This subclass will be returned
>>> using an alternate url(...) call, e.g. murl(...).
>>>
>>> So my urls.py will look like -
>>> urlpatterns = patterns('project.app.views',
>>> murl(r'^/(?P\d+)(?#format)$', AppView.as_view(),
>>> name='app_view1
Re: making URL resolving/reversing gradually more flexible
On 12 November 2010 23:14, burc...@gmail.com wrote: > First I thought you're going to return some instance with reverse > which has get_possibilities. > And you just want RegexURLPattern to register 3 usual regexes for you > instead of one. Effectively. I should've been more concise when writing the initial email :) > Could you please create a patch now -- at least someone will use it. Will do. It'll help iron out any possible quirks in my proposal too. > Maybe you also thought of a patch for this specific case of simple > reversible ORs in the urls? > Examples: (a|b|c) and (?Pa|b|c) I have, and I'm happy to have a look at fixing that, but it'll definitely not make release 1.3. I'm not sure how open the core devs are to non-core devs poking around in core parts of the framework though. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: settings.py should have way to hide key/values even when debug set True
On 1 February 2011 17:26, Alex Gaynor wrote: > How, precisely, would one apply a decorator to an assignment statement? > Unless there has been some change to Python's grammar I'm not aware of, > decorators can only be used on function and class definitions. You could wrap the value on the right of the assignment operator with a decorator I think. For some reason I don't feel comfortable with this though. > Alex > > -- > "I disapprove of what you say, but I will defend to the death your right to > say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Decision for ticket #6362 - Remove blank spaces with strip when validating the data
On 5 July 2011 02:20, Jacob Kaplan-Moss wrote: > Doesn't do anything to change my point, though: a framework can't go > about stripping user input. That's a user-code decision. If Django > strips out data I wanted, there's nothing I can do to get it back. I concur. The consensus seems to be shifting towards a 'strip' flag though (defaulting to false), and I'm +1 on that. That would make it explicit, minimise repetitive boilerplate code and also make it less likely to accidentally forget to strip a field somewhere in the process. Maybe a revisit to this related ticket is in order? https://code.djangoproject.com/ticket/4960 > Jacob > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to django-developers@googlegroups.com. > To unsubscribe from this group, send email to > django-developers+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Unit tests error out with WinError 10013 in my Windows 7 machine with Python 3.3.2
Do you have anything running on port 8081 (running netstat will tell you)? I just ran Django's test suite on my machine (Windows 7, Python 3.3.2), from the trunk cloned an hour ago, and it completed mostly without an issue (there's a UnicodeDecodeError but that's likely because it's printing a character to stdout that isn't supported by the Windows console codepage). Can you move this discussion over to django-users (just post your reply with the rest of the email chain over there)? I don't think it's an issue with Django itself. On 25 October 2013 02:46, Antony J wrote: > Hi, > > Good morning. > > Your help is needed: > > I am relatively new to Django. After developing a Django app, I am trying to > write my first patch for Django. > > I checked out Django from github: VERSION = (1, 7, 0, 'alpha', 0). > > When I run the unit tests with the command "python runtests.py", I get 6 > errors and 2 failures. > But in the Django Jenkins server, the builds are successful. > > The error is: OSError: [WinError 10013] An attempt was made to access a > socket in a way forbidden by its access permissions > > I tried the following: > > 1) Ran a command prompt as administrator. > 2) Added python.exe to firewall inbound rules. > 3) There are some suggestions for this error in stack overflow: > http://stackoverflow.com/questions/2778840/socket-error-errno-10013-an-attempt-was-made-to-access-a-socket-in-a-way-forb > http://stackoverflow.com/questions/16908529/python-3-x-socket-error-errno-10013-an-attempt-was-made-to-access-a-socket-in > > The first suggestion seem require code changes in Django, and the second > suggestion seem require code changes in Python http/server.py. > > But these suggestions do not seem right to me. > > I am running a Windows 7 Enterprise OS (version 6.1) with Python 3.3.2 > 32-bit version. > > Is this a supported config to build Django? > Have any of you faced this error? > > I appreciate any help that you can provide to solve the errors and failures. > Please find the error and failure tracebacks in the text file attached > herewith. > > Thanks, > Antony > > -- > 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/8f23755c-be2b-4a24-a00e-aaaead7f78ab%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/CABxbXqVcPxX6e5jrevAiPXoMJbD4%2BPv6is%3DFVtDjXjDFwynrYg%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: 1.6 reverse() escapes unreserved chars in path components
The relevant commit and issue -
https://github.com/django/django/commit/31b5275235bac150a54059db0288a19b9e0516c7
https://code.djangoproject.com/ticket/13260
On 1 March 2014 17:26, Erik van Zijst wrote:
> Django's django.core.urlresolvers.reverse() seems to have changed its
> behavior in 1.6. It now runs the arguments through quote(), without
> specifying the safe characters for path components. As a result:
>
> on 1.4.10:
> In [2]: reverse('test', args=['foo:bar'])
>
Out[2]: '/foo:bar'
>
> but on 1.6.2:
> In [2]: reverse('test', args=['foo:bar'])
> Out[2]: '/foo%3Abar'
>
> It would seem to me that this is a regression, as ":@-._~!$&'()*+,;=" are
> all allowed unescaped in path segments AFAIK.
>
> Cheers,
> Erik
>
> --
> 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/064ba557-a722-484f-93bf-423048b51b14%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/CABxbXqXKhcKFPS8ufmYDGmgHU_QjBuFUb%3DaFXk3FROJyzAJw5A%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: 1.6 reverse() escapes unreserved chars in path components
I wasn't expressing an opinion either way; just adding the relevant
commit to the conversation.
Looks like RFC 3986 is the relevant RFC describing the permitted
characters in URIs, specifically section 2.2 and 2.3 -
http://tools.ietf.org/html/rfc3986#section-2.2
It seems like the fix makes it easier for 90% of the uses, but
explicitly blocks the other 10% (i.e. uses involving the use of
'reserved' characters as permitted by the RFC).
The relevant django-developers discussion is here -
https://groups.google.com/forum/#!searchin/django-developers/13260/django-developers/Gofq5y40mYA/v_4yjrBItWkJ
The final post addresses this issue, but doesn't seem to have been
taken into account when the patch was accepted.
On 2 March 2014 12:28, Erik van Zijst wrote:
> On Sat, Mar 1, 2014 at 2:41 PM, Sam Lai wrote:
>> The relevant commit and issue -
>>
>> https://github.com/django/django/commit/31b5275235bac150a54059db0288a19b9e0516c7
>> https://code.djangoproject.com/ticket/13260
>
> Yes I saw that, but I'm confused. I thought these characters are
> allowed unescaped in path segments.
>
>
>> On 1 March 2014 17:26, Erik van Zijst wrote:
>>> Django's django.core.urlresolvers.reverse() seems to have changed its
>>> behavior in 1.6. It now runs the arguments through quote(), without
>>> specifying the safe characters for path components. As a result:
>>>
>>> on 1.4.10:
>>> In [2]: reverse('test', args=['foo:bar'])
>>> Out[2]: '/foo:bar'
>>>
>>> but on 1.6.2:
>>> In [2]: reverse('test', args=['foo:bar'])
>>> Out[2]: '/foo%3Abar'
>>>
>>> It would seem to me that this is a regression, as ":@-._~!$&'()*+,;=" are
>>> all allowed unescaped in path segments AFAIK.
>>>
>>> Cheers,
>>> Erik
>>>
>>> --
>>> 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/064ba557-a722-484f-93bf-423048b51b14%40googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Django developers" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/django-developers/ZLGk7T4mJuw/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/CABxbXqXKhcKFPS8ufmYDGmgHU_QjBuFUb%3DaFXk3FROJyzAJw5A%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/CA%2B69USsj%2BuWHJJfw7-Fr8SFq34Xq0TLThR3Bq2t3r66K9oAFrw%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/CABxbXqU903Ry9x04%2Bu%2B%2BVaQKnrHH2e1mLwXkjr2YenhYku%2Bsng%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: requiring login to perform Trac actions?
On 4 March 2014 10:44, Russell Keith-Magee wrote: >> If you believe the "create an account" barrier is a problem, do you think >> adding something like GitHub auth to Trac would lower the barrier to an >> acceptable level? > > > This sounds like a reasonable option to me. Any halfway serious potential > contributor should have a Github account, and it matches Django's own > toolchain. The oAuth process is pretty smooth, so the problem set is down to > "users who are genuinely new to software". I've worked in a few industries where developers have never heard of git, even if they spend their whole day on a Linux box and are definitely not 'new to software'. That said, it is possible that the subset who use Django are probably likely to be familiar with GitHub given that Django is a web framework. Maybe some explanatory text at the login screen would mitigate the issue. Also, will GitHub oAuth actually solve the sporadic login issues? -- 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/CABxbXqU9PmCdp%3D4EOZoEJD4C4SP5j45srhGoxJfR2ZRqe0HtLQ%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: The greatest proposal yet: rename this damn group
FYI, this comes up again and again here, but the core devs have shot it down repeatedly. Here's one from last year - https://groups.google.com/d/msg/django-developers/yJYkZEGUzVk/u5xiIzg_TtMJ For the record though, I think renaming it to something less ambiguous is a good idea. On 5 September 2014 12:57, Robert Grant wrote: > Yeah I like that one. > > Or django-verlords. > > On Friday, 5 September 2014 13:36:23 UTC+2, Piotr Buliński wrote: >> >> +1 >> My proposition: django-contributors >> That’s pretty self-explanatory, confusion-avoiding name. >> >> Cheers, >> Piotr >> >> On 05 Sep 2014, at 09:58, Robert Grant wrote: >> >> > I am one of the happy few who read the line about what this group is for >> > before I started posting. >> > >> > However, that line, and the endless supply of people who think this is >> > for Django developers (see also: Java developers are generally considered >> > to >> > be people* who develop in Java, not who develop Java), might be symptoms of >> > the fact that this group has a funny name for something that is both >> > developed and developed in. >> > >> > Can we rename it? :) Some semi-serious suggestions (because I can't >> > think of an obvious alternative) : >> > >> > Django Masters >> > Django Private >> > Django Debate >> > Django Internals >> > Aymeric And Friends >> > >> > >> > >> > >> > >> > * Yes, they're still people. >> > >> > -- >> > 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. >> > To view this discussion on the web visit >> > https://groups.google.com/d/msgid/django-developers/fd27a285-be01-417f-ab4b-4026d7221239%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" 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/8e2ff58a-a2d0-412c-8d95-4930bd0783db%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" 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/CABxbXqUksvOAbZyuqDHsQ9c185iyCHLz58T4XwAVY2iW30Jr2A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
