Do we actually need to deprecate the current backend and create a new one?
Can't we just rewrite the current backend? Technically changing a
dependency doesn't require deprecation, does it? It's also a very simply
update process.
On Monday, November 25, 2019 at 6:46:05 AM UTC+7, Adrian Turjak
Hi Mariusz,
Cool, let me know if you have any questions about the config file that I wrote.
I am happy to help :)
Regarding the output, yes I can feel you. However I don’t know if we really
need to run tests at verbosity level 2 on CI. One can always do that online or
enable it if need be.
s part
> of docker-box that we can use.
>
> Tom
>
> > On 9 Nov 2019, at 08:40, Johannes Hoppe wrote:
> >
> > > Then why not use all the work already done in django-docker-box there?
> > >Then this would be "Run Django CI with Docker in the Azur
> Then why not use all the work already done in django-docker-box there? Then
>this would be "Run Django CI with Docker in the Azure cloud via Github Actions
>instead of Jenkins via the Jenkins-Github integration (plugin?)”
@Matematica that sounds promising is there a PR for that, that I have
o 31. lokak. 2019 klo 11.39 Johannes Hoppe
> kirjoitti:
>
>> I am trying to understand the motivation to use an "old" Django 2.2 but a
>> "bleading edge" Python version. I can understand Nicks logic of people
>> needing to upgrade form Python 2 to 3 and
points, I added some comments inline.
On Fri, Nov 8, 2019, 09:42 Matemática A3K wrote:
>
>
> On Thu, Nov 7, 2019 at 11:31 AM Johannes Hoppe
> wrote:
>
>> Hey Tom,
>>
>> Good to hear for you and very good points. I'll leave you a couple of
>> inline comments:
&g
Good idea Carlton, here you go
https://code.djangoproject.com/ticket/30964#ticket
On Friday, November 8, 2019 at 3:03:58 AM UTC+9, Carlton Gibson wrote:
>
> Please open an issue for the macOS failure. It’s been passing for me all
> week so... 樂
>
> On Thu, 7 Nov 2019 at 17:31,
ely agree.
>
>
> If this plan sounds reasonable then let's create some smaller tickets. IMO
> the exact specifics of how the database tests will look is still fuzzy, but
> for the linting it’s perfectly clear. However if anyone is not happy with
> actions in the main
for almost 2h now. I wonder if I could run a
major web service of a GitHub action :P
On Thursday, November 7, 2019 at 8:15:43 PM UTC+9, Johannes Hoppe wrote:
>
> I put in a little effort and tried a couple of conceptual things.
> 1. YAML anchors, inheritance and includes are not yet supported
hing yet, and I am not sure
it's a big time saver, since Django doesn't have many dependencies.
On Thursday, November 7, 2019 at 1:44:00 PM UTC+9, Johannes Hoppe wrote:
>
> @Florian, dependent builds or build stages are possible, seealso:
> https://github.com/coding
@Florian, dependent builds or build stages are possible, seealso:
https://github.com/codingjoe/django/commit/eeefc83a85ba5e91b98c4e29fb9b20896612cc8c/checks?check_suite_id=299641652
--
Johannes Hoppe
www.johanneshoppe.com
Want to chat? Let's get a coffee!
https://calendly.com/codingjoe/call
Wow, the response has been much bigger than expected. That's great, it's
good to know that this is a topic people are invested in. It shows me two
things:
1. There is a certain degree of dissatisfaction about the current setup.
2. There is enough interest to support a more community driven
Apolloner wrote:
>
> Hi,
>
> yes I had the same thought yesterday. I think trying with linters first
> should be an easy low hanging fruit (and to get a feeling for it). Tests in
> general might get a bit harder.
>
> Cheers,
> Florian
>
> On Thursday, October 31, 20
I am trying to understand the motivation to use an "old" Django 2.2 but a
"bleading edge" Python version. I can understand Nicks logic of people
needing to upgrade form Python 2 to 3 and Debian by default gave them
Python 3.7.
Following that narrative, maybe we should check what the major
Auth0 looks like a need solution! And yes, I am a bit YubiKey fan myself. Use
it for 2FA and PGP, worth every penny.
--
On 25. Apr 2019, 17:38 +0200, Александр Овчинников ,
wrote:
>
> > IMHO Django should provide a secure and simple (for developers) out of the
> > box solution.
>
> I can't
So I spend a little time fiddling around Django to understand what is possible
and where there might be room for API improvements.
I went with the hardest possible way, NO password, NO username. Just one time
passwords send via email or SMS. Similar to Django’s password reset function.
I
Hi there,
@Florian, since I had so many PRs pending review, I had to find other ways
to cause chaos ;)
Besides that I agree, this isn't an easy undertaking and a lot of time will
need to be spend on the whiteboard to get this going. Maybe it is worth
actually collecting a little bit of money
Hi Claude,
Very good point. I am not familiar with the translation process. I think we
would benefit from the linter. It’s not so much a linter in the traditional
sense, since it’s not linting any code. It rather finds small errors in
translations files. Inconsistencies in punctuation, line
I don't think that a Docker image would make local development any easier.
I also don't see how that is implied by the reddit post and it's comments.
Looking through the posts, I agree with the assessment, that most people
currently lean towards a microservice architecture and therefore towards
, Shai Berger , wrote:
> Hi,
>
> On Mon, 26 Nov 2018 00:57:04 -0800 (PST)
> Johannes Hoppe wrote:
>
> > I want to address a completely different point, and that
> > *innovation*. I believe that 3rd party backends could lead to more
> > innovation in the Djan
How about we do pretend like we want to remove the backends from core and do
the homework and refactor the backends to be less intertwined but keep them in
the same repo/package. Maybe that’s how we can have the best of both worlds. It
is going to be harder to motivate people to put in the work
To quote the documentation:
https://github.com/orf/django-docker-box/blob/85780dcc81d62a4c0c1142b45eb69e825d97b074/README.md#oracle
"As usual Oracle is a bit more complex to set up.” ;)
--
Johannes Hoppe
www.johanneshoppe.com
Want to chat? Let's get a coffee!
https://calendly.com/codi
Hahaha, yes kind of :P
If they become a corporate sponsor it shut up immediately ;)
On Monday, November 26, 2018 at 9:08:13 AM UTC+1, Carlton Gibson wrote:
>
> Hi Joe!
>
> On 26 Nov 2018, at 09:05, Johannes Hoppe > wrote:
>
> I don't mind putting in extra work for an
On Monday, November 26, 2018 at 9:49:46 AM UTC+1, Florian Apolloner wrote:
>
> Hi,
>
> I personally agree with Mariusz here. Oracle might have it's own quirks,
> but the same could be said for any database. Taking my experience with the
> ORM into account I do not think that Oracle requires
I want to address a completely different point, and that *innovation*. I
believe that 3rd party backends could lead to more innovation in the Django
ORM.
Currently if you want to introduce a new feature for your database, you are
faced with a lot of complications added by databases you might
acle does not run in the regular CI suite, in fact master is
>> broken right now
>>
>> I don't see any failures in djangoci.com. Maybe you use an unsupported
> version of Oracle?
>
> Best
> Mariusz
>
>
> W dniu niedziela, 25 listopada 2018 11:21:02
A college just referred this new package to me:
https://github.com/wildfish/django-gdpr-assist
On Tuesday, August 28, 2018 at 11:14:51 AM UTC+2, Vasili Korol wrote:
>
> I outlined the problem of parent domain cookies included in Django's error
> reports, which may be a problem due to GDPR.
>
Hi Curtis,
very good remarks. I would make sense to provide the best possible preset
for such a middleware. That could even be content-type sensitive.
I would however add any settings to overwrite the preset. I believe if
someone want to mingle with those things, one should inherit and
t regards,
>
> --
> Aymeric.
>
> Le ven. 14 sept. 2018 à 10:01, Johannes Hoppe > a écrit :
>
>> Hi there,
>>
>> we all know the the wonderful GZip middleware that allows response
>> compression. Which is great especially if you are serving la
u be looking at merging any code from django-brotli, and have you
> been in contact with its creator and license holder Vasek Dohnal?
>
> And what kind of methods around Accept-Encoding are you imagining?
>
> On Fri, 14 Sep 2018 at 09:01, Johannes Hoppe > wrote:
>
>> Hi the
Hi there,
we all know the the wonderful GZip middleware that allows response
compression. Which is great especially if you are serving large responses.
Now gzip is only one of many supported encoding types supported by many
browsers. The coolest kid on the block seems to be brotli right now.
for users anyways.
Good thinking tho, brilliant.
Best
-joe
--
Johannes Hoppe
www.johanneshoppe.com
Want to chat? Let's get a coffee!
https://calendly.com/codingjoe/coffee
Lennéstr. 19
14469 Potsdam
USt-IdNr.: DE284754038
On 27. Aug 2018, 09:12 +0200, Brice Parent , wrote:
> Hi Joe,
>
ing. Maybe even a warning wouldn't be necessary.
>
I am with you on that one. There is no need to prevent the other. Maybe it
does boil down to a crisp sentence in the documentation that encourages
users to use the new feature.
>
> On Sat, 25 Aug 2018 at 21:05, Johannes Hoppe >
Hi there!
I do need some feedback on the best public API to implement multi file
support to Django forms.
Context:
Up until now Django forms do not support multi file upload. You will need
to write your own view to handle the files as described here:
Proposal) as well as a public tutorial. The tutorial
should point out best practices on how to deal with personal or sensitive
personal data. How to provide interfaces to ensure portability, the right
to be forgotten or processed.
Best
-Joe
--
Johannes Hoppe
www.johanneshoppe.com
Want to chat? Let's
OK, I drafted an implementation for django.forms.FileField to support
`multiple` as an argument.
https://github.com/django/django/pull/9011
I would appreciate some feedback. If you like the design, I’ll try to add
documentation and better tests tomorrow.
Thanks
-Joe :)
--
Johannes Hoppe
Fon
when it
comes to clearing initial values. Have separate checkboxes might also prove to
be a UX issue, since users would need to check them all individually.
What do you guys think? Am I on the right track regarding this issue?
--
Johannes Hoppe
Fon: +49 331 2812 9869 1
Fax: +49 331 2812 9869 9
available to a broader
audience.
Thanks everyone :)
--
Johannes Hoppe
Fon: +49 331 2812 9869 1
Fax: +49 331 2812 9869 9
www.johanneshoppe.com
Lennéstr. 19
14469 Potsdam
USt-IdNr.: DE284754038
On 2. Sep 2017, 10:37 +0200, Adam Johnson <m...@adamj.eu>, wrote:
> I agree with Melvyn on the fi
can be of any
help.
Cheers
-joe
On Thursday, August 31, 2017 at 6:30:37 PM UTC+2, Johannes Hoppe wrote:
>
> Hi there!
>
> I already created a ticket regarding this matter, but I think this thicket
> requires some discussion prior to crafting a solution.
> https://code.django
Hi there!
I already created a ticket regarding this matter, but I think this thicket
requires some discussion prior to crafting a solution.
https://code.djangoproject.com/ticket/28554
The django.db.models.FileField currently allows only to store a single file
URL.
This behavior seems outdated
Hi there,I worked on a fix for form media today. No it will keep the order and we can include our own scripts before calling noConflict.This way we don't have to wrapp all vendored JS libraries.Furthermore it makes the order of your assets more reliable than before and throws a warning if there
pgrade the admin's copy of jQuery to the
latest release in each Django major version, but I'm not sure if doing
that and dropping noConflict woudl be a hindrance to third-party apps
that want to support multiple Django versions.On Tuesday, June 6, 2017 at 5:54:16 AM UTC-4, Johannes Hoppe wrote:Hi!I didn
Hi!
I didn't get your name, but this address the latest post.
I think we made some good progress in the regarding this issue. The
inclusion of select2 is at a stage where I wouldn't want to jump to a
different library. Especially considering that now one acted at this ticket
for seven years
Hi there!
Regarding reusing the admin widget:
I would advice highly against it. It made for the admin and requires models
to be registered there. It would be better to use django-select2, which is
where the autocomplete_fields are originating from.
At the current point I don't see how we could
Hi Sven,
you are right. For this particular case select2 would be an ill advice. But
I didn't initially add support for m2m fields. I just added it later to my
pull-requested, since it was only one line of code. And some people would
have found a usecase for It.
At the end this will be an
stin <aymeric@polytechnique.org
>> > wrote:
>>
>>> I’m OK with this. It's a reasonable solution.
>>>
>>> --
>>> Aymeric.
>>>
>>> On 06 Apr 2016, at 15:25, Johannes Hoppe <in...@johanneshoppe.com
>>> > wrote:
>&
Hi,
as promised I started working on an autocomplete field for
`django.contrib.admin` as a more convenient alternative to `row_id_fields`.
We had a longer discussion in the ticket and also at the sprints at
DjangoConEU with some of the maintainers for famous 3rd party autocomplete
I got that, but you can't just make it your default widget, it will always
require more information. And I don't really like "defaults", again pep20.
I currently don't have any need for action, therefore I won't do anything. If
you want to make a draft on how to refactor it, I'm happy to
(pep20). We made the field definition in
ModelForms mandatory and a lot of other “assumptions” have been deleted in
recent releases.
> On Mar 9 2016, at 3:26 pm, James Pic james...@gmail.com wrote:
>
> On Wed, Mar 9, 2016 at 3:09 PM, Johannes Hoppe
i...@johanneshoppe.com wrote:
We'll you can change the `default` form Field using
`django.db.models.Field.formfield`.
But that is actually the thing I don't like I think this needs to go: https://
github.com/django/django/blob/d5f89ff6e873dbb2890ed05ce2aeae628792c8f7/django/
db/models/fields/__init__.py#L869-L905
But at
Hi Tim, and I guess that's you James?
Thanks for pointing me towards this discussion. Tho I do like the idea for
the sake of `django-select2`, I think it's a bad idea for Django.
I don't think that `django.db` should be even aware of `django.forms`. I
don't even like the current implementation
51 matches
Mail list logo
