date:20190817

Re: Django LTS support time

2019-08-17 Thread Pkl

Hello Uri,

my (unsurprising) two cents: this is less a problem with the time span of 
the LTS version, than of the API stability / upgrade ease / django 
compatibility (recently discussed in this thread 
).

In the current state of affairs, I advise you to upgrade your application 
to latest stable Django version, using a compatibility helper like my 
https://github.com/pakal/django-compat-patcher if you have compatibility 
conflicts with your codebase or your dependencies (if some compatibility 
fixers are missing for your own needs, please open an issue or contact me).

best of luck,

regards,
Pascal Chambon




On Friday, August 9, 2019 at 9:31:25 AM UTC+2, Uri wrote:
>
> Django Developers,
>
> I would like to know why Django LTS support time is 3 years. I think with 
> Ubuntu LTS it's at least 5 years. We are using Django 1.11 for Speedy Net, 
> which was released on April 2017, and I'm not sure we will be able to 
> upgrade it before April 2020. There are changes which are not backward 
> compatible, we will have to change some of our code if we upgrade Django, 
> and some packages we are using, such as Django Crispy Forms, we have to use 
> versions which don't support Django versions higher than 1.11 due to bugs 
> in future releases (
> https://github.com/django-crispy-forms/django-crispy-forms/issues/889). 
> Upgrading to the next LTS version (2.2) will take lots of time, and the end 
> of support of 2.1 is December 2019. I want to release Speedy Net and Speedy 
> Match to production soon, and I don't think we will be able to upgrade 
> Django before 2020. It would help if there was 5 years support for each 
> Django LTS version. What do you think?
>
> אורי
> u...@speedy.net 
>

-- 
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/3a17a325-0433-45dd-ae7f-2db3b3689b8f%40googlegroups.com.

Django Chat Application using channels and SQS

2019-08-17 Thread Varun Jain

*Problem Statement: *Build a scalable chat infra using django/python, do
assume that you will have to scale this horizontally.

I am still to get the other specifics about the product expectations but
here is what I understand matters:

a. Acceptable Latency between messages/events
b. Number of open connections/user possible per server
c. Size of messages/payload (more on this in a minute).

This is what my solution needs to look like (generic, not specific to
django/python)

*Client Web Socket Component (CWSC)*
A group of servers that can:

a. Accept an incoming user's connection request over web socket protocol
and initiate a sticky session.
b. Accept messages/events from a user
c. Receives messages/events received for the connected user and passes it
on to the frontend client
d. Stores the messages in a persistent db (PostgreSQL)
e. *Broadcasts the message to a pub/sub style channel *for other servers
to listen for.

*Central Redis User-Server Map*

Since we are assuming a distributed system the two users might not be on
the same server. In this case we need to know the receiver user's server
(so that it can added as meta-data to the message broadcasted by CWSC).
This meta data can be used the receiving server to filter messages meant
for it as the pub/sub channel broadcasts to all server's subscribed to a
particular channel.

This db would hold the a mapping of user to server. Whenever a new
connection request happens (a) above, it would also add an entry to the
redis db.

*Pub/Sub Channel *

This is where messages/events are broadcasted. Assuming simplicity of only
one type of event it would only have channel, that all servers would have
subscribed to. Other types of channels could be (message read event,
picture sending event etc)

Here is my understanding of how this can be done using django-channels:

1. Django channels is the CWSC component here. It provides for a handy
framework to write the implementations

2. Pub/Sub channel is the *channel layer *concept within django-channels
that uses *channel_redis * as the backend.

3. Central redis user-server map is just something I came up with for my
design and can be a very simple EC2 server running the same.

Here are my questions:

1. How does using django channels compare to using socket module directly
in python? In terms of performance/scalability. I am not looking for a
silver bullet here and understand that it is all a question of product
specifics but is it reasonable to expect it to scale to half a million
users without us having to open up the package and make modifications to
it? My understanding of django-channels is that it is built on socket in
python but in a django-friendly manner.

2. Is channel_redis using redis pub/sub underneath?

3. Can I use something like Amazon SQS instead of channel_redis? If so any
relevant resources/packages would be great.

4. Is there something else you would want me to know?

--
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/35606039-9d10-4ed2-9926-46dd9febf765%40googlegroups.com.

Re: Ideas for a new DEP on long-term Django API compatibility

2019-08-17 Thread Carlton Gibson

Hi Pascal.

> On 17 Aug 2019, at 18:21, Pkl wrote:
>
> In just 5 lines of discussion...

Just for the record, we spent a good time discussion this change (to bring
inheritance of Admin Actions in line with Python’s expected inheritance rules).
We reviewed the entire history of the feature. We explored an alternative
approach, which would have maintained BC. We put the discussion to the mailing
list, where further people reviewed it, and we came to a decision, as a group,
without any objections being raised.

We didn’t make this decision lightly.

On balance, we felt the breaking change was justified by the ease of adaption,
the fact nobody could identify a single use-case of the existing behaviour in
the wild — and to be fair, there have not been issues raised because of it,
which we might have expected — and finally, that Django would be better for the
change.

I’m sorry that we have a different approach than the one you’ve asked for, but
hopefully you can accept the reasons that people have given, and, more
importantly, that decisions are made in good faith, for the best outcome that
we, as a group, can find.

Kind Regards,

Carlton

Re: Django LTS support time

2019-08-17 Thread Aymeric Augustin

Hello,

Actually an individual attempted this for Django two years ago: 
https://web.archive.org/web/20170710090735/https://djangolts.com/ 


The website disappeared after a year. I don't know what happened. The quick 
death suggests there wasn't a ton of demand, though.

-- 
Aymeric.



> On 14 Aug 2019, at 15:13, Josh Smeaton  wrote:
> 
> I don't think the DSF has the capacity or the will to run a business offering 
> paid support contracts.
> 
> But nothing is stopping an enterprising individual or company from doing so. 
> All security patches are made public (eventually) and backporting fixes would 
> be fairly low effort. https://railslts.com/  is prior 
> art in this space.
> 
> I'm incredibly surprised no one has started up a business to do this for 
> Django.
> 
> On Tuesday, 13 August 2019 10:32:21 UTC+10, 1337 Shadow Hacker wrote:
> Actually I'm pretty sure it could be done even if DSF kept a profit, to 
> re-inject it into other developments for exemple. AFAIK the major difference 
> between non-profit and company is that you don't own it and as such you 
> cannot take dividends out of it personally. IMHO everybody would benefit if 
> DSF did more commerce and was stronger by that mean. I could sing an ode to 
> commerce but that would be much off-topic.
> אורי if you're looking for commercial extension you can certainly hire 
> someone for that for the time being, Patryk's company seems to have willing 
> developers, or hire someone to face the debt in your codebase, which Patryk's 
> company will probably recommend for the same budget. Sorry for being so 
> binary but unless another idea emerges from this topic...  it seems pretty 
> cornered at this point, sorry for not being more helpful.
> 
> Best of luck
> 
> -- 
> 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/ce923775-e684-43ad-ae16-e6db236e04d7%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/E8C7A3C7-B98A-4097-84C3-99B2DE03C045%40polytechnique.org.

Re: Ideas for a new DEP on long-term Django API compatibility

2019-08-17 Thread Jason Johns

Pascal, I don't think anyone here disagrees with your overall goal to 
reduce the breaking changes.  As someone that got handed a 1.2 project with 
zero tests and updated it to 1.8, good test coverage to lay the foundation 
for reviving an ambitious project that went comatose before being 
prioritized again, the amount of breakage and updating required was 
surprisingly small.  It took about a month or so to do, and a quarter of 
that was setting up staging and prod environments on AWS.  The core devs 
here have done a great job, in my opinion, of keeping the breaking changes 
to a minimum, and making them in a thoughtful manner with an eye to the 
future.

Tech debt is a very real thing.  Keeping it under control is vital to the 
pace of improvement and updates for any project, large, middling or small.  
Any project requires maintanence at minimum, just like owning a car or 
house.  If you buy a car and run it every day for five years, only filling 
up the gas tank and adding a splash of oil now and then,  you don't have 
any excuse to be upset at the mechanic or manufacturer for the size of the 
repair bill when things start breaking.  At least with software, its alot 
easier to get fixes out than with hardware.  You make a persuasive argument 
and have great passion, but the overall goal of enabling out of date and 
unsupported releases to remain around longer than they should be makes me 
feel really uncomfortable.  A spftware project is not buy once and forget, 
neither is a car.  And your package seems to encourage that lax practice to 
a level that I would be highly resistant at working at a company if I 
couldn't persuade management to prioritize keeping up to date and tech debt 
at a manageable level.

Open source has a pretty low barrier to entry, and django projects like the 
ones you listed on django packages are reflective of that.  Its easy to 
make a package and put it out, but maintaining and iterating and releasing 
take alot more in terms or time, effort and emotional state.  Fortunately, 
Python as a whole seems to be much easier on package devs than the JS 
community, but as I'm sure Carlton, Adam, Tim, and anyone that's published 
a package with requests for support can attest, it can get exhausting.  
That's when packages just die on the vine.  Some are lucky to 
be resuscitated by another dev taking over, or forking the original, but 
that doesn't happen for the majority.  Deliberately going out of your way 
to ensure that old code which hasn't been looked at in however long and was 
last working on two LTS releases ago gives me a very squicky feeling in my 
stomach.  

-- 
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/097ecac4-0596-40d4-a069-7e8d2c879ce9%40googlegroups.com.

Re: Django LTS support time

Django Chat Application using channels and SQS

Re: Ideas for a new DEP on long-term Django API compatibility

Re: Django LTS support time

Re: Ideas for a new DEP on long-term Django API compatibility

5 matches

Site Navigation

Mail list logo

Footer information