Re: Adding ability to choose AutoField type (signed vs unsigned)

[Florian Apolloner]

On Tuesday, April 6, 2021 at 7:08:06 PM UTC+2 Adam Johnson wrote:

> I also don't think this is necessary any more and can be closed.
>  
>
>> An explicit `id = PositiveBigIntegerField(...)` workaround would be fine 
>> to be honest, for those that need it.
>
>
> I also would like to meet the django app that *does* need it (for 
> non-silly reasons like deciding to start ID's near 2^63).
>

Since you have asked: It is required if you want to store a x509 
certificate serial number as is. We indeed get queries from integrators 
that have previously stored serial numbers in a big integer field. After 
the "recent"  cert library updates which now properly produce 64 bit 
positive integers like the CAB forum requires, they ran into plenty of 
problems with the first certificate serial that was larger than 2^63.

Map that to Django and I think changing to PositiveBigIntegerField is a 
fair workaround. Not sure if it is worth changing the default, but the 
requirements do exist for some people.

Cheers,
Florian

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2a5a9a02-70d6-4f77-9af0-c9217cb9eb3an%40googlegroups.com.

Re: GSoC Proposal: (Migrations) Adapt schema editors to operate from model states instead of fake rendered models.

[Carlton Gibson]

Hi Manav. 

You should definitely submit. Your proposal is quite detailed, so I'd need 
to sit down with it more fully than I have time to comment on this week. 
(But that's OK — even if your implementation idea needs revision, THAT 
you've considered it is important.) 

Having said that: 

* You have "testing & docs" tacked on at the end in your schedule. Identify 
the phases and include time to write the tests as you go. In phase 1, how 
will you know that your central registry is correctly tracking model 
relationships unless you write tests? (You won't...)

* Maybe you did this already but, review the points Simon Charette made in 
the thread on this topic last year: 
https://groups.google.com/g/django-developers/c/_ohBzsuomqw/m/cEI8eoK7BQAJ 
— There are large parts of a solution to this problem there. It would be 
good if on review your proposal uses Simon's suggestions. 

Please do use this week to make your proposal as good as you can and 
submit. (I can't see that I'll have capacity to review another draft, but 
equally you should have enough to go on now.) 

I wish you luck! 

Kind Regards,

Carlton


On Wednesday, 7 April 2021 at 08:13:54 UTC+2 dpsma...@gmail.com wrote:

> Thank You Carlton for the feedback.
>
> As per your suggestion, I have increased the clarity of the proposal 
>  with 
> some code and implementation. I will try to maximize the clarity as much 
> as possible.
>
> Till then, May you please suggest, that Shall I share my proposal as a 
> draft at GSoC Portal .
>
> Also, it would be great if you may suggest the possible improvement areas 
> in the proposal 
> , or 
> does it seems fine?
>
> Regards
> Manav Agarwal
>
> On Tue, Apr 6, 2021 at 7:09 PM Carlton Gibson  
> wrote:
>
>> Hi Manav. 
>>
>> Sorry for the late reply. 
>>
>> Your proposal looks very good, and your previous contributions are 
>> noticed. 
>> You’ve obviously taken time to look at it in depth. 
>>
>> I think just going over it this week as time allows to maximise clarity 
>> is worth it. That’s always time well spent. (Generally there are a lot of 
>> applications, so making yours stand out as focused and to the point both 
>> demonstrates your capacity and makes the reviewer’s job easier.) 
>>
>> I hope that helps. 
>>
>> Kind regards, Carlton 
>>
>> On Mon, 5 Apr 2021 at 05:12, Manav Agarwal  wrote:
>>
>>> Link for the proposal - 
>>> https://gist.github.com/manav014/9b0feb734e4d140eef1913340602d2ae
>>>
>>> On Monday, April 5, 2021 at 8:41:32 AM UTC+5:30 Manav Agarwal wrote:
>>>
 I have added the proposed solution in the proposal. 
 I request fellow developers to please help me with their respective 
 suggestions, thoughts or feedback, so that I may develop a better and 
 practical proposal.

 Regards,
 Manav Agarwal

 On Friday, April 2, 2021 at 3:09:46 AM UTC+5:30 Manav Agarwal wrote:

> Hello everyone,
> My name is Manav. I’m a Computer Science and Engineering junior at Dr. 
> A.P.J. Abdul Kalam Technical University in India.
> I started contributing to Django in October 2020 and have solved many 
> issues 
> on trac 
> 
> .
> I read through the GSoC Idea List and the Migration topic stood out 
> for me. I found the idea to adapt schema editors to operate from model 
> states instead of fake rendered models really interesting.
> I am working on this for the last 1 month and I have made myself 
> familiar with the whole migrations framework codebase. I drafted a basic 
> proposal 
>  
> in which I would be updating the complete solution after some discussion 
> to 
> make the solution more concrete, practical, and effective.
> The problem with the Migration framework is briefly described in the 
> proposal 
>  
> itself. 
> After understanding the problem I came up with a few solutions which 
> are listed below:
>
>1. As Suggested by @MarkusH 
>, A central registry to 
>store all dependencies in django.apps.registry.Apps
>
>Or
>
>2. Designing a new metaclass for ModelState just like we have 
>ModelBase 
>
> 
>  
>for Model. As then we would be able to use Options 
>
> 

Re: GSOC Proposal : Adding a Redis cache backend to Core

[Daniyal Abbasi]

Hi
Since redis does not support complex objects, we need to serialize the data
into a suitable format. Most third-party libraries use either the pickle
module, to serialize the values or use json / yaml serializers. I want to
move ahead with using the pickle module. However, does it seem necessary to
add support for other serializers ( json / yaml / msgpack ) as well?

Regards,
Daniyal Abbasi


On Thu, Apr 1, 2021 at 4:16 AM Daniyal Abbasi 
wrote:

> Hey
> I am an aspirant  for GSOC 2021. I was really interested in the project
> "Adding a Redis cache backend to Core" as I myself have used third party
> libraries to integrate redis as a caching backend. A link to by draft
> proposal can be found here
> .
> I have shared this draft proposal to the gsoc dashboard too.
>
> Regards,
> Daniyal Abbasi
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHcKF3F2HVS%2BjZvpnuZbmiC-D3yg%3Dz4_QCsAM4qV9D-GzZ2Jbg%40mail.gmail.com.

django-amp-tools project improvement

[Pratham Jangra]

Hello developers

This is Pratham Jangra, a Computer Science & Engineering undergrad 
sophomore.

For GSoC 2021, I am making a proposal to solve some problems in the 
django-amp-tools project. The most important one is to create a library for 
auto-parsing HTML tags.

 

Importance: As we all know AMP is used by a massive amount of websites for 
webpages to load faster and get pages optimized for mobile browsing. 
Nowadays AMP is heavily used for user-first websites, stories, ads, emails. 
It is widely used for SEO in websites as Google prefers it and gives the 
website a higher ranking.

 

Problems/Ideas: AMP uses equivalent HTML tags to optimize a particular 
webpage. But there are still some issues yet to be resolved as follows:

   - 
   
   AMP is based on components
   - 
  
  Not all tags have equivalent representation in HTML which is a big 
  issue because day by day content is increasing on AMP pages and we will 
  eventually need those tags to render the pages. This is the problem I 
have 
  faced personally while using AMP boilerplate for a website. There is no 
  amplify tag equivalent.
  - 
  
  Translation is still a big issue for AMP.  Currently all HTML cannot 
  be translated.
  - 
  
  Automatic parsing: If there is a way to automatically parse all tags 
  of HTML then most of the issues of equivalent representation in AMP will 
be 
  solved. for e.g. . All we would need to do is create a library to 
  automatically create an AMP-equivalent page of the existing HTML page.
  - 
  
  Need for stabilize the parsing.
  
I did my research as much as possible but still some issues are there and 
we can create a new library for auto-parsing the tags in normal HTML. My 
proposal is still in work and I would really appreciate feedback and 
suggestions on these issues. Please advise me to implement any other 
features and if there is anything wrong in the whole idea. I am open to any 
new ideas; and please correct me if I have missed anything in the whole 
idea. Thank you.

 

Regards

Pratham Jangra

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/fa290e47-6ee9-4136-9a72-368fdc2da9ddn%40googlegroups.com.

Re: GSoC Proposal: (Migrations) Adapt schema editors to operate from model states instead of fake rendered models.

[Manav Agarwal]

Hey Carlton.

I have submitted the proposal.
Also, Your suggestion of adding tests with the introduction of a new
central registry seems great and I have implemented the same in phase 1.
Also, I already added all the points suggested by Simon Charette from the
discussion(
https://groups.google.com/g/django-developers/c/_ohBzsuomqw/m/cEI8eoK7BQAJ).
Last but not least, I will try to make my proposal more clear in the coming
week till the deadline.
I understand that as the proposal is detailed you will have to sit down
with it more fully but you don't have time for the same and It's totally
fine.

Thank You for your suggestions that always help a lot.


On Wed, Apr 7, 2021 at 7:09 PM Carlton Gibson 
wrote:

> Hi Manav.
>
> You should definitely submit. Your proposal is quite detailed, so I'd need
> to sit down with it more fully than I have time to comment on this week.
> (But that's OK — even if your implementation idea needs revision, THAT
> you've considered it is important.)
>
> Having said that:
>
> * You have "testing & docs" tacked on at the end in your schedule.
> Identify the phases and include time to write the tests as you go. In phase
> 1, how will you know that your central registry is correctly tracking model
> relationships unless you write tests? (You won't...)
>
> * Maybe you did this already but, review the points Simon Charette made in
> the thread on this topic last year:
> https://groups.google.com/g/django-developers/c/_ohBzsuomqw/m/cEI8eoK7BQAJ
> — There are large parts of a solution to this problem there. It would be
> good if on review your proposal uses Simon's suggestions.
>
> Please do use this week to make your proposal as good as you can and
> submit. (I can't see that I'll have capacity to review another draft, but
> equally you should have enough to go on now.)
>
> I wish you luck!
>
> Kind Regards,
>
> Carlton
>
>
> On Wednesday, 7 April 2021 at 08:13:54 UTC+2 dpsma...@gmail.com wrote:
>
>> Thank You Carlton for the feedback.
>>
>> As per your suggestion, I have increased the clarity of the proposal
>>  with
>> some code and implementation. I will try to maximize the clarity as much
>> as possible.
>>
>> Till then, May you please suggest, that Shall I share my proposal as a
>> draft at GSoC Portal .
>>
>> Also, it would be great if you may suggest the possible improvement areas
>> in the proposal
>> , or
>> does it seems fine?
>>
>> Regards
>> Manav Agarwal
>>
>> On Tue, Apr 6, 2021 at 7:09 PM Carlton Gibson 
>> wrote:
>>
>>> Hi Manav.
>>>
>>> Sorry for the late reply.
>>>
>>> Your proposal looks very good, and your previous contributions are
>>> noticed.
>>> You’ve obviously taken time to look at it in depth.
>>>
>>> I think just going over it this week as time allows to maximise clarity
>>> is worth it. That’s always time well spent. (Generally there are a lot of
>>> applications, so making yours stand out as focused and to the point both
>>> demonstrates your capacity and makes the reviewer’s job easier.)
>>>
>>> I hope that helps.
>>>
>>> Kind regards, Carlton
>>>
>>> On Mon, 5 Apr 2021 at 05:12, Manav Agarwal  wrote:
>>>
 Link for the proposal -
 https://gist.github.com/manav014/9b0feb734e4d140eef1913340602d2ae

 On Monday, April 5, 2021 at 8:41:32 AM UTC+5:30 Manav Agarwal wrote:

> I have added the proposed solution in the proposal.
> I request fellow developers to please help me with their respective
> suggestions, thoughts or feedback, so that I may develop a better and
> practical proposal.
>
> Regards,
> Manav Agarwal
>
> On Friday, April 2, 2021 at 3:09:46 AM UTC+5:30 Manav Agarwal wrote:
>
>> Hello everyone,
>> My name is Manav. I’m a Computer Science and Engineering junior at
>> Dr. A.P.J. Abdul Kalam Technical University in India.
>> I started contributing to Django in October 2020 and have solved many 
>> issues
>> on trac
>> 
>> .
>> I read through the GSoC Idea List and the Migration topic stood out
>> for me. I found the idea to adapt schema editors to operate from model
>> states instead of fake rendered models really interesting.
>> I am working on this for the last 1 month and I have made myself
>> familiar with the whole migrations framework codebase. I drafted a basic
>> proposal
>> 
>> in which I would be updating the complete solution after some discussion 
>> to
>> make the solution more concrete, practical, and effective.
>> The problem with the Migration framework is briefly described in the
>>

Re: GSoc proposal : A django pdfs library.

[Anuttam Anand]

Hey Carton ,
I have made my final proposal , please let me know for any additional 
points or advice.
Google Docs Link 
: 
https://docs.google.com/document/d/1HPi0hI3BlVRuUiq2JPxKxm_jnGwjfqhCczWaDHUWhSE/edit?usp=sharing

On Tuesday, April 6, 2021 at 10:16:26 PM UTC+5:30 Anuttam Anand wrote:

> Hey Carlton,
>
> Thanks for responding . This is my first open source project and I'm 
> pretty scared . But my view is to add features for a django pdf library , 
> features which other frameworks have and are not in current scope like in 
> ReportLab.
> After doing some research , I have found some python based APIs and 
> existing libraries , not very refined but possible to use with django. 
> Since they require a lot of dependencies, making a whole package of the 
> thing will be more efficient for the user. I hope you and all others can 
> give me more advice and if you people know anymore libraries or similar 
> packages. P.S if you guys have any more features which you think a pdf 
> conversion package should have , I would be glad to hear them.
> Again thanks 
>
> - Anuttam Anand
>
> On Tuesday, April 6, 2021 at 7:16:22 PM UTC+5:30 carlton...@gmail.com 
> wrote:
>
>> Hi Anuttam. 
>>
>> I’d guess that a PDF library itself would be out of scope for Django 
>> itself — but this is a perennial problem. 
>>
>> **Quite maybe** a project to modernise the Outputting PDFs with Django 
>> docs would be in scope... 🤔
>>
>> https://docs.djangoproject.com/en/3.1/howto/outputting-pdf/
>>
>> Questions that you could cover: 
>> What is the best way to do it these days? What dependencies does that 
>> involve? 
>> Are there helpers we could add to Django? (And so on.) 
>>
>> An awesome proposal there might swing it. (I can’t say definitely.) 
>> (Even if it didn’t make GSoC, such a proposal would convert well into a 
>> profile blog piece, so if you’re keen it might be worth the punt.) 
>>
>> I hope that helps. 
>>
>> Kind regards, Carlton 
>>
>> On Mon, 5 Apr 2021 at 15:58, Anuttam Anand  wrote:
>>
>>> Hello to all my djangomates. I am Anuttam Anand, Btech student from 
>>> India. For this year's GSoc , I am thinking of making a proposal for a more 
>>> efficient and feature containing pdf library. Upon researching , I found 
>>> ReportLab to be the pdf making library in django but it lacks many features 
>>> and has been reported to be buggy. 
>>> Features which I am thinking of including:
>>> 1. A direct webpage conversion to pdf and containing atleast 80% of css.
>>> 2. An option to download or keep the pdf in the server itself , location 
>>> parameter which is specified by the programmer.
>>> 3. An option to download the pdf to the user's device upon calling the 
>>> function.
>>> Motivation:
>>> 1. The main motivation behind this project is that many websites need 
>>> pdfs like transaction receipts or some reports which are downloaded.
>>> 2. I personally faced this issue a while ago and has to manually 
>>> download my webpages to contain the css as some other libraries do download 
>>> the pdf but results in loss of css and thus the design and quality.
>>>
>>> I hope to get an opinion and advice and if I have missed some package or 
>>> if anyone thinks of some more features, I will be happy to listen.
>>>
>>> Thanking You
>>> Anuttam Anand
>>>
>>> -- 
>>> 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-develop...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/django-developers/d38880c2-c67c-47c5-adc4-6fe016b2160bn%40googlegroups.com
>>>  
>>> 
>>> .
>>>
>>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/a4390bd9-134b-4405-91ef-d4be22800169n%40googlegroups.com.