python-memcached is deprecated, but still used in core Django

2019-11-24 Thread Adrian Turjak 
A while ago now I opened a ticket that we need to deprecate the
python-memcached backend in Django, and ideally make a new one which
uses Pinterest's pymemcache instead (which is now the most commonly used
one).

This is the ticket:
https://code.djangoproject.com/ticket/29887

But it seems there hasn't been any work on it. Someone assigned
themselves, but nothing beyond that has happened.

At this stage we really need to remove the docs that recommend
python-memcached, and the backend associated with it, and say officially
that only pylibmc is a valid and safe option from the core backends
using Memcached.

Considering how important Memcached is to a lot of projects, this ought
to be a high priority item, with some urgency given that Django core is
sporting support for a now very deprecated and outdated library (Last
released: Dec 16, 2017), with no future, and a clear successor in
pymemcache.

I'm sadly not in a position where I can contribute this myself, but
would be happy to test/review. Are there any willing contributors for
this? Or some people from the Django core team which will tackle this?

Cheers,
Adrian Turjak




-- 
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/6b110940-e059-2550-b1da-d94b62de5e59%40catalyst.net.nz.

Re: python-memcached is deprecated, but still used in core Django

2019-11-25 Thread Adrian Turjak 
That's a tough question. It depends on when and how we do it. A new
backend can potentially be backported to 2.2 (the current safe LTS), but
we can't really update the existing one if people are using it and
expect it to work. Django doesn't actually have any deps for these
libraries, so people have to install them as part of their app deployment.

A new backend, even if mostly a copy of the old one, is the safer
approach and then people need to actively switch to it, and be aware of
it. We then deprecate the old one, and we can backport to 2.2 the new
safe one, and remove the old one in never versions.

On 25/11/19 11:05 pm, Johannes Hoppe wrote:
> 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 wrote:
>
> A while ago now I opened a ticket that we need to deprecate the
> python-memcached backend in Django, and ideally make a new one which
> uses Pinterest's pymemcache instead (which is now the most
> commonly used
> one).
>
> This is the ticket:
> https://code.djangoproject.com/ticket/29887
> <https://code.djangoproject.com/ticket/29887>
>
> But it seems there hasn't been any work on it. Someone assigned
> themselves, but nothing beyond that has happened.
>
> At this stage we really need to remove the docs that recommend
> python-memcached, and the backend associated with it, and say
> officially
> that only pylibmc is a valid and safe option from the core backends
> using Memcached.
>
> Considering how important Memcached is to a lot of projects, this
> ought
> to be a high priority item, with some urgency given that Django
> core is
> sporting support for a now very deprecated and outdated library (Last
> released: Dec 16, 2017), with no future, and a clear successor in
> pymemcache.
>
> I'm sadly not in a position where I can contribute this myself, but
> would be happy to test/review. Are there any willing contributors for
> this? Or some people from the Django core team which will tackle
> this?
>
> Cheers,
> Adrian Turjak
>
>
>
>
> -- 
> 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
> <mailto:django-developers+unsubscr...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/a5eaf9cc-21aa-4cb8-9d61-9fc8e76e0733%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/a5eaf9cc-21aa-4cb8-9d61-9fc8e76e0733%40googlegroups.com?utm_medium=email&utm_source=footer>.

-- 
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/28b2116b-6592-acfc-5726-68764676639f%40catalyst.net.nz.

Re: python-memcached is deprecated, but still used in core Django

2019-12-08 Thread Adrian Turjak 
A backport probably isn't needed, but I strongly urge deprecation. The
library has had a few failed attempts at pick up, but ultimately those
who wanted to do that just moved to pymemcached, and anyone else
sensible will do the same. There is no need or want to maintain
python-memcached when a strong opensource alternative exists that is
backed by pintrest. I reached out to some of the people who were looking
at picking up maintaining it, but they never got any response back from
the current project owner, and going through the hassle of getting it
from them via pypi admins is a waste of time when pymemcached is the
clear winner in the pure python memcached library space.

python-memcached is dead for all intents and purposes, and with no
release since Dec 16, 2017 is in a bad place for us to not deprecate. As
such, this is bad for us, and looks bad for Django that we still
recommend this library as the first option when using memcached.

On 26/11/19 7:51 pm, Mariusz Felisiak wrote:
> TIcket #29887 doesn't qualify for a backport so if someone prepare a
> patch then we can include it in the Django 3.1. Also, I don't see a
> strong consensus for deprecating python-memcached support. It can
> found a new maintainer in the nearest future.
>
> Best,
> Mariusz
> -- 
> 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/ce2804d3-8e41-4105-bcd3-0860e26b24e8%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/9ee512fb-e4e3-f233-1f99-9f6b0b814b13%40catalyst.net.nz.

Re: declarative settings

2020-02-25 Thread Adrian Turjak 
Declarative settings, and a lack of a good settings file parsing system,
led me into some rather interesting directions not that long ago.

I maintain an OpenStack project called Adjutant, and I built it on
Django, but ended up using yaml as my config file and having settings.py
read it and pull in certain values. But I ended up doing some rather
weird nested stuff, and kept introducing small sections of code that
needed some config value. But because I didn't have a way to declare
those configs somewhere, it essentially turned into a nightmare to know
exactly what values were configurable, and where in the code they were used.

OpenStack uses a config library system called oslo.config which allows
declaring config, and then consuming it. Sadly for me that didn't handle
nesting. dynamic config registration... or too much weird complexity.
Plus it was based off INI files, and didn't support yaml or toml. So I
ended up writing my own variant which did.

The library I wrote is:
https://gitlab.com/catalyst-cloud/confspirator

And the way I use it:
https://github.com/openstack/adjutant/tree/master/adjutant/config
https://github.com/openstack/adjutant/blob/master/adjutant/settings.py

Which this being how I handle my plugins, and their config:
https://github.com/openstack/adjutant/blob/master/adjutant/feature_set.py

The whole thing is maybe a little over the top, but it allows dynamic
config registration via plugins, declarative values, so you can't ever
use a config without defining it, and it can read those config values
from envvars or you can pass it a dict structure to parse (which you can
load in from json, yaml, or toml).

And a way to then use that config tree to generate example config:
https://github.com/openstack/adjutant/blob/master/adjutant/commands/management/commands/exampleconfig.py

This may not be what you need, but given my random pain in what I think
is a similar area, I thought I may as well share. I do intent to
maintain CONFspirator, and will be adding native support for
parsing/loading yaml/toml, as well as utils for example config
generation soon.

On 31/12/19 11:45 am, Christian González wrote:
> Hello,
>
> I recently "finished" my first really working version of GDAPS, my
> Generic Django Application Plugin System. It's noway perfect, but does
> what it should: providing pluggable apps for an app framework, including
> a more or less flexible frontend with each django app.
>
> I had much struggle with it, and one of the lessons I learned was
> Django's setup system, and how it deals with loading apps. Unfortunately
> Django can't load/unload apps on the fly, so it is necessary to restart
> Django whenever a new GDAPS app is installed via pip.
>
> But: I want to resurrect an old theme again which would, in a way,
> improve some of the loading problems I encountered. Django's settings
> are code. Which is, in fact, a very good thing, as it makes it extremely
> flexible and adaptable to different setups. But, as discussed with the
> SECRET_KEY here, some of the settings _have_ to be coded very
> complicated, and it makes some things like per-app-settings extremely
> uncomfortable.
>
> What if - and please don't kill me instantly - yes, I am a newcomer, and
> not a good programmer maybe - but some things are viewed better from
> "outside" - what if Django settings could be "declarative"?
>
> So instead of Python code like
>
> INSTALLED_APPS = [
>     'django.contrib.admin',
>     'django.contrib.auth',
>     'django.contrib.contenttypes'
> ]
>
> This would be in an e.g. JSON file
>
> {
>
>     "INSTALLED_APPS": [
>         "django.contrib.admin",
>         "django.contrib.auth",
>         "django.contrib.contenttypes"
>     ] ,
>     ROOT_URLCONF: "fooproject.urls"
> }
>
> Django's settings.py would look different: It would load that
> settings.json file and set the appropriate values into local code - so
> this wouldn't make much difference.
>
> Except 2 things:
>
> 1. Apps could have (default) settings, and they could be merged MUCH
> easier. Things like namespaced classes that are overwriting values like
> DRF/graphene does, would be completely unnecessary. The main
> settings.json file could be the "last word" in the process of settings,
> so anything an app would suggest could be overrided in the main file.
>
> 2. Installed apps could be managed much more comfortable. Adding an app
> could be done by a script (JSON editing is easy. Editing code
> (=settings.py) is error prone and uncomfortable). I have a Django
> command script ATM for that, but just because I add a line into
> settings.py to add some additional apps to the list.
>
> This even could be done with backwards compatibility, because Django
> would keep it's settings.py file optionally:
>
> * read json settings (if they exist), use them
> * load settings.py which allows to override them again (using some
> special code tricks like dynamic loading, environments etc.)
>
> Please tell me what you think about that.
>
> Christi

python-memcached seems to be unmaintained

2018-10-28 Thread Adrian Turjak 
Through some of my last few projects using Django and Memcached I kept
running into the problem that python-memcached appears to no longer be
maintained[1], and even before that the release frequency was getting
quite low.

For Django pylibmc is an alternative, but having to rely on an
underlying C library is a bit annoying and the library does act a little
differently.

Give the state of python-memcached I think Django should support
pymemcache[2]. It is actively maintained by Pintrest, with appropriate
opensource licensing, is fully python, and appears to be a great library.

There appear to have been attempts by thirdparties to make a Django
cache backend for it, but none of those are maintained. Bringing the
support into core, and replacing python-memcached with pymemcache may be
a better good long term solution than continuing to support and
recommend an unmaintained library when there is a suitable alternative.

I opened this ticket here to track that, and the recommendation was to
bring it (rightly so) to the mailing list:
https://code.djangoproject.com/ticket/29887

I'm also a member of the OpenStack community and I've talked to devs who
were interested in taking over python-memcached as per the discussion in
the linked issue, but it looks like OpenStack's oslo.cache is also
switching to pymemcache at this stage because it offers them a great
alternative.

Any thoughts?


1: https://github.com/linsomniac/python-memcached/issues/95
2: https://github.com/pinterest/pymemcache

-- 
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/3ad5467c-8073-7273-ae5b-00f5dd713efa%40catalyst.net.nz.
For more options, visit https://groups.google.com/d/optout.

Re: Python string formatting

2018-10-31 Thread Adrian Turjak 
There was a push to deprecated % formatting but too many people complained and that never happened.While .format and g-strings are superior, % is here to stay for the foreseeable future. Too many people still use it (including myself sometimes).On 1 Nov. 2018 08:14, Carlton Gibson  wrote:We had a bit of a discussion of this on Python 2 docs have got this re format(): > This method of string formatting is the new standard in Python 3, and should be preferred to the % formatting described in String Formatting Operations in new code.​https://docs.python.org/2/library/stdtypes.html#str.formatBut it's not there for Python 3 (​https://docs.python.org/3/library/stdtypes.html#str.format) so I'm not clear what we're meant to think. (I had thought %-formatting deprecated...) Anyone know? Regardless, waiting a bit and moving straight to f-strings (as Simon suggests) seems sensible. (If we're convinced we do want to change.)



-- 
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/e7cf5b0d-cff4-4c6d-a9ec-1af4a82d5a56%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.




-- 
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/6b09193b-a53f-4eb4-9f36-2c7aa11f47cb%40email.android.com.
For more options, visit https://groups.google.com/d/optout.