Re: Removing url() ?

[Bruno Alla]

I've started working on a tool provides a set of codemodders 
 for Django:

https://github.com/browniebroke/django-codemod

It's based on Instagram's libCST 
 (work with Concrete 
Syntax Tree). This is very much a work in progress, but I think it could 
help with these kind of deprecations that require changing a lot of files. 

I'm not really satisfied by the API of the CLI, I would prefer to get 
something like pyupgrade, where you specify your min & max Django version, 
but I guess it's better than nothing.

It's very much a work in progress and feedback is welcome!

On Saturday, 9 May 2020 17:13:51 UTC+1, Adam Johnson wrote:
>
> Automated upgrade tooling would be great. Developers end up building their 
> own anyway.
>
> One more tool we could copy is pyupgrade ( 
> https://pypi.org/project/pyupgrade/ ). It's based upon an extension to 
> 'tokenize' by the author (Anthony Sottile) that allows roundtripping (which 
> I guess would be useful being merged to the stdlib). But it also looks 
> possibly painful to work with.
>
> I've tried Bowler and it has a nice interface, allowing git-add-patch 
> presentation through its idiff() command. But it doesn't have many examples 
> in its documentation, which made me give up. It's also based on lib2to3, 
> through a separated copy called fissix.
>
> codemod's README lists Python 2 support only :(
>
> regexes for find/replace, maybe with a sed command, would be the lowest 
> common denominator. Combined with "git add --patch", then "git checkout ." 
> that's basically what codemod does (afaiu).
>
> On Sat, 9 May 2020 at 13:32, Aymeric Augustin <
> aymeric...@polytechnique.org > wrote:
>
>> Hello,
>>
>> When proposing deprecations that require numerous but simple code 
>> changes, providing an automated upgrade path could reduce frustrations 
>> about "useless churn".
>>
>> Unfortunately, I don't know a great way to do that on Python code. Here 
>> are the options I'm aware of:
>>
>> - Writing 2to3 fixers is painful, in my experience 
>> .
>>  
>> Also, I don't think that 2to3 will survive the deprecation of lib2to3; 
>> removal is scheduled for Python 3.12.
>> - Bowler  seems designed to make it less painful, 
>> but is also written on top of lib2to3, so not a long term solution.
>> - codemod  gives up fully automated 
>> refactoring (which is at odds with Python's dynamic nature) and attempts 
>> "computer-aided refactoring".
>> - Most likely IDEs like PyCharm can rename an import throughout a project.
>>
>> If I had to do something in this area, I'd try codemod, probably.
>>
>> Of course, it will still be boring to perform the same change across N 
>> projects for no direct project-level upside, but at least it may require 
>> less time and less focus.
>>
>> This is relevant for the thread about renaming request.GET/POST/etc. If 
>> we proceed with that change, we're bound to have the exact same discussion 
>> about removing the original names.
>>
>> Best regards,
>>
>> -- 
>> Aymeric.
>>
>>
>>
>> On 5 May 2020, at 17:41, Collin Anderson > > wrote:
>>
>> Hi All,
>>
>> Are we _sure_ we want to completely get rid of url()?
>>
>> Yesterday, url() was given a RemovedInDjango40Warning [PR]. The removal 
>> was approved as part of the new path() syntax back in 2017 [DEP 0201].
>>
>> Is this really worth it? It's only a *few lines of code* to keep 
>> backward compatibility, and it seems to me it would take *almost no work 
>> to maintain* that compatibility shim compared to the countless 
>> programmer hours needed to upgrade their code, including many unpaid 
>> programmers working on open source projects. I'll personally need to do a 
>> find/replace for url() to re_path() across my ~20 projects, and update all 
>> of the imports. Isn't this *useless code churn*?
>>
>> Yes, there's an advantage to having one and only one way to do it, so I 
>> agree we should encourage people to use re_path() instead of url(), but 
>> shouldn't we also make it *as easy as possible to upgrade django*? Is 
>> getting rid of url() really worth the cost?
>>
>> Yes, the removal is still ~3+ years away, but that's a question of _when_ 
>> not _if_.
>>
>> If we want, we _could_ deprecate url() without giving it an actual 
>> removal date [Compatibility Discussion] and leave the compatibility shim 
>> around longer, if not indefinitely.
>>
>> Thanks,
>> Collin
>>
>>
>> [PR] https://github.com/django/django/pull/12855
>>
>> [DEP 0201] 
>> https://github.com/django/deps/blob/master/final/0201-simplified-routing-syntax.rst
>>
>> [Compatibility Discussion] 
>> https://groups.google.com/d/topic/django-developers/asqnjcYPnms/discussion
>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "Django developers

Re: Django security releases issued: 2.1.6, 2.0.11, and 1.11.19

[Bruno Alla]

It looks like 2.1.6 has unexpected new migrations as well 
https://code.djangoproject.com/ticket/30174

 Did something go wrong during the release publication?

On Monday, 11 February 2019 12:07:19 UTC, Raffaele Salmaso wrote:
>
> On Mon, Feb 11, 2019 at 12:25 PM Riccardo Magliocchetti <
> riccardo.ma...@gmail.com > wrote:
>
>> InvalidTemplateLibrary: Invalid template library specified. ImportError 
>> raised 
>> when trying to load 'django.contrib.admin.templatetags.base': cannot 
>> import name 
>> getfullargspec
>>
>> 1.11.18 works fine for the same test.
>>
> Hi Riccardo, please check if you use the correct django version, 
> django.contrib.admin.templatetags.base is there from django 2.1
>
> -- 
> | Raffaele Salmaso
> | https://salmaso.org
> | https://bitbucket.org/rsalmaso
> | https://github.com/rsalmaso
>

-- 
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/b6656afc-c8d5-47bf-8127-b5643e6145e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Explore integrating django-docker-box in some way?

[Bruno Alla]

Just a note that as a newish contributor to Django, this django-docker-box 
is fantastic, it makes things much easier to setup. 

Thank you to everyone involved!

On Wednesday, 5 December 2018 00:02:27 UTC, Tom Forbes wrote:
>
> To have this completely working at sprints without having everyone 
> building their own local images we would need to have the Jenkins server 
> use docker in some capacity. This would also require an official django 
> account on Docker hub.
>
> The pattern I’m using right now is that on every build we pull the 
> django-ci:latest image (from my personal account). Docker uses this image 
> as a cache automatically (preventing rebuilds). On any successful master 
> build we push the new image to docker-hub, so subsequent builds can utilise 
> it.
>
> Then anyone wanting to speed up their bootstrapping can do docker-compose 
> pull and automatically have the latest image available for running right 
> away. We can make this smaller, for sure, but we can also suggest people 
> download this beforehand (i.e at their hotel).
>
> I don’t know how feasible this is but it’s also very easy to run a caching 
> docker mirror (docker run -p 5000:5000 registry). Organizers could run 
> this at large events and configuring docker to use a local mirror on the 
> network is a one-line change for atendees.
>
>
>
>
> On 4 December 2018 at 23:52:42, Josh Smeaton (josh@gmail.com 
> ) wrote:
>
> Size of the image could definitely be a concern, especially at sprints 
> where wifi speeds aren't always optimal. The django-box image is 
> significantly larger though so it'd still be a net win. There are also 
> optimisations that can be made to the image for reducing size over time, so 
> I'd fully expect it to come down. I've spent a little bit of time trying to 
> optimise a $work$ python docker file, I'll provide what I've got as an 
> issue to possibly look at. 
>
> I see that the ticket has been accepted and I think that's a great step 
> forward. I'd also like to hear from the infrastructure team what their 
> thoughts on using docker over customised build environments would be.
>
> Florian, Tim, Markus .. any thoughts? (Apologies, I've missed some, this 
> list of names is from memory).
>
> On Wednesday, 5 December 2018 10:39:16 UTC+11, Tom Forbes wrote: 
>>
>> Thank you for the reply Josh. I didn’t anticipate any suggestions for 
>> including this inside core but off the back of your suggestion I’ve made a 
>> ticket here: https://code.djangoproject.com/ticket/30010.
>>
>> I don’t think it should be complex at all to include this inside Django - 
>> it’s four or five new files at most. Hopefully this should improve the 
>> experience at sprints, however the current Dockerfile weighs in at 650+mb 
>> so the problem may switch from ‘it is hard to set up an environment’ to ‘it 
>> is hard to download one’!
>>
>>
>>
>> On 5 November 2018 at 23:02:30, Josh Smeaton (josh.s...@gmail.com) wrote:
>>
>> I'm sorry I haven't had the time to review or contribute yet, but I think 
>> it'll be a very useful project - especially for new contributors that might 
>> have a little docker experience. The current vagrant solution is heavy, 
>> does not work properly on windows and some linuxes, and isn't that easy to 
>> maintain or deploy. I'd be in favour of adding the docker files directly to 
>> django/django to minimise setup burden (DJANGO_PATH), and improving the 
>> contributing docs to show users how to test using docker. 
>>
>> One of the hardest things I found at sprints was getting development 
>> environments setup to effectively contribute - even using the docker-box 
>> project which I understand quite well. Anything we can do to improve that 
>> situation will be very beneficial.
>>
>> I have fewer opinions about the official CI story, hopefully some of the 
>> infrastructure team can comment more on that. I think that replacing the 
>> ansible roles with a docker setup can have some definite improvements and 
>> open up CI tasks to a larger pool of people (anyone that can edit docker 
>> files), but it'd come with maintaining the host that runs docker (cleaning 
>> up images, dealing with disk space issues, etc).
>>
>>
>> On Monday, 5 November 2018 01:20:03 UTC+11, Tom Forbes wrote: 
>>>
>>> Hello all,
>>>
>>> I’ve been working on a docker-compose based alternative to django-box 
>>> (imaginatively named django-docker-box) over the last month and it 
>>> finally appears to be mostly complete.
>>>
>>> For reference the tool is just a Dockerfile and a docker-compose 
>>> definition that is able to run a complete test matrix of every supported 
>>> Python and DB version. It’s as simple as docker-compose run sqlite. You 
>>> can see a full test run (excluding oracle) here: 
>>> https://travis-ci.com/orf/django-docker-box/builds/90167436
>>>
>>> Florian suggested I create a thread here to gather feedback and discuss 
>>> any potential future directions for the project, so here goes:
>>>
>>> Firstly I’