I'd like to propose moving Django issues to github and make a real decision
on it here in this thread. If there has been a recent discussion on this I
apologize, but searching for issue tracking / github links to about every
thread ever posted here.
I believe this would lower the barrier to
Yes, I think this change makes sense, assuming no unexpected difficulties arise
in the implementation.
> On 6 Aug 2019, at 10:58, Janez Kranjc wrote:
> Hi guys! I’m Janez Kranjc, I’ve been using Django for a bit now - since 1.3
> and I’ve recently come
This was discussed before, when we moved from self-hosted svn to GitHub-hosted
git, but I'm not sure there are public archives of all discussions.
As far as I remember, the main points to tackle are:
1. Does GitHub allow "anonymous triage" i.e. labelling, closing, and reopening
What prevents the change to the API endpoints so it will have language
prefix as well?
On Wed, Aug 7, 2019 at 1:56 PM Aymeric Augustin <
> Yes, I think this change makes sense, assuming no unexpected difficulties
> arise in the
Nothing prevents the change to the API endpoint except the fact that users
are actively using the API already and (it is my opinion) that a change in
another part of the application - like a sales page - shouldn't affect the
working of an unrelated part of the project. Also that would mean
To put it short, the barrier to entry is far too high and difficult for
newcomers and even long time users of Django.
I agree with others sentiment that there isn't anything that trac can do
which github issues cannot, especially for the overwhelming majority of
tickets. As a long time user
You bring up a lot of good points. There will undoubtedly be challenges and
huge amount of work in moving to a new system, or implementing any big
sweeping changes, however, I truly honestly believe that it would be worth
it in the long run, and the payoff would far outweigh the
Another problem that is specific to APIs (which are not really the point
here, just an example) is that using prefixed URLs that has the default
language also prefixed - prefixing API urls during the lifetime of the
application would break the API for specific users because the previous
Mariatta has put together a some PEPs for migrating CPython issues over to
https://www.python.org/dev/peps/pep-0581/ proposing the migration.
https://www.python.org/dev/peps/pep-0588/ migration plan.
Django and Cpython are not the same, so there'll be substantial
differences. But it's
The more I use Trac, the more I appreciate its power. I'm normally all for
Progress™ but I'm not sure GitHub's UI is up to it.
(Being able to find the old discussion is super handy: it's not that often
that an idea has not come up before at this stage.)
*I'd be interested to see what a
I think you've found the wrong mailing list for this post. This mailing
list is for the development of Django itself, not for support using Django.
This means the discussions of bugs and features in Django itself, rather
than in your code using it. People on this list are unlikely to answer
This my first post here, so excuse me if I am breaking any convention. I am
thinking of how useful if we can create a minimal version of django using
something as follow:
python manage.py createservice
So instead of creating full fledged project, we create a project (service)
please anyone help me out its urgent..
On Tue, 6 Aug 2019 at 19:56, vishal singh wrote:
> can anyone help me to pull all table name(schema wise ) from database
> into a dropdown.
> it will be best if someone give codesnippits or examples , how to do??
You received this message because
Week ending August 4, 2019.
https://code.djangoproject.com/ticket/30665 - Add DISTINCT support for Avg
and Sum aggregates. (accepted)
https://code.djangoproject.com/ticket/30662 - Add a signal at the end of
I don't have a very strong opinion here, but replying with some questions,
and to bump the thread.
I think this smells more like a bug than a feature to me. I worry that if
you depend on it, it could easily get refactored away in a future version
of Django. If we were to document it
We actually discussed this a little at the PyCon AU sprints and the
consensus was that GitHub issues would be great *if only they were a bit
The problems I feel are specifically an issue:
- Ticket states; this is not easily replicated with labels, while
components etc. are
Did you know startproject takes a URL for the template? See docs:
https://docs.djangoproject.com/en/2.2/ref/django-admin/#startproject . You
could use this to provide your microservice template in a separate
location, for example a GitHub repo with a download URL.
For more advanced
Like Adam Johnson has said, i think you should use stackoverflow or any
django facebook group for this post.
On Wed, Aug 7, 2019 at 5:16 PM vishal singh
> please anyone help me out its urgent..
> On Tue, 6 Aug 2019 at 19:56, vishal singh
>> can anyone help me to pull all
I want to thank you all for your time and input. I'll start doing some
research into how cpython and others are managing this. I will draw up a
few options and present them so we can better work out the possibilities
and details before submitting a process DEP. I don't want to submit
Would it be possible to expand the scope of the recently accepted secret
key rotation ticket to include the ability to live rotate other credentials
as well, such as the DB credentials?
Or would this be a separate thing all together?
TL;DR: I think this is a bug and can lead to inconsistencies in other project
setups than yours.
Let's look at the last question first, regarding duplicate entries in the
django_migrations table: Yes, this is to be a bug. At least how it's currently
Let's say you have
Actually I do not know, and I completly agree with you, we only need a new
template not new management command. Many thanks.
بتاريخ الأربعاء، 7 أغسطس، 2019 7:16:44 م UTC+3، كتب Adnan Muttaleb:
> This my first post here, so excuse me if I am breaking any convention. I
Mail list logo