What's the state for Centos? I think it was the last likely distro we cared about with old python needs, but I'm not sure core supports it at all any more.
On October 1, 2017 2:12:46 PM PDT, Abhilash Raj <maxking(a)asynchronous.in> wrote:
>Hi All,
>
>Mailman uses Django web framework for the web based frontends,
>Postorius
>- The Official UI, and Hyperkitty - The official Archiver. They are
>both
>Django "apps" which means that they can be plugged into any other
>existing Django "project" (aka Django "installation") to work alongside
>other apps that people might be running.
>
>Currently, both the Django apps we have are Python 2 only, we have
>talked about moving to Python 3 but we decided we want it to be
>bilingual (support both 2 & 3). The reason we decided that was because
>if people would want to embed Postorius & Hyperkitty in their
>installations, they need to be able to run it under whatever python
>versions they are using.
>
>I want to revisit this assumption for being bilingual. Currently, there
>is no supported version of Django which doesn't support Python 3.
>Starting from v2.0, set to release in December 2017, Django is going to
>drop Python2 support. Now, that doesn't mean no one can run Django
>under
>Python2, 1.11 (LTS version) supports Python2 and will be supported
>probably till Python 2 is supported (April 2020 according to [1]).
>
>I believe that our (limited) development efforts would be best utilized
>if we just drop the support for Python 2 in Postorius & Hyperkitty
>instead of trying to be bilingual. Any day one of our dependencies may
>decide to do the same, and we would have to then use Python 3 anyway.
>Also, dropping Python 2 support doesn't seem like a lot of pain for
>anyone, you just need another instance of Django running, which is not
>*that* hard using uwsgi (in Emperor mode). I believe most of our
>dependencies should support Python 3, or should have a good enough
>replacement if it doesn't.
>
>
>Thoughts?
>
>[1]: https://www.djangoproject.com/download/
>
>--
> Abhilash Raj
> maxking(a)asynchronous.in
>_______________________________________________
>Mailman-Developers mailing list
>Mailman-Developers(a)python.org
>https://mail.python.org/mailman/listinfo/mailman-developers
>Mailman FAQ: http://wiki.list.org/x/AgA3
>Searchable Archives:
>http://www.mail-archive.com/mailman-developers%40python.org/
>Unsubscribe:
>https://mail.python.org/mailman/options/mailman-developers/terri%40toybox.ca
>
>Security Policy: http://wiki.list.org/x/QIA9
On 10/08/2017 02:16 PM, Abhilash Raj wrote:
>
> This is the command that Gitlab CI runs, the environment variable below
> is what
> mailman uses for "extra" testing config.
>
> $ MAILMAN_EXTRA_TESTING_CFG=/home/runner/configs/mysql.cfg tox -e
> py35-nocov-mysql
>
> The extra mysql.cfg is what holds the database configuration.
Thanks Abhilash. What I didn't realize is since I already have a mysql
server running on my dev box for other purposes, I had to use that
server and create a 'mailman' database within it and then use
appropriate credentials to access it.
I can now actually run tests using mysql. My results in this case are
different from the original issue at
<https://gitlab.com/mailman/mailman/issues/385> because my server is not
running in "strict" mode., but I can now work on the original issue
since I can actually test any fixes.
--
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
I'm trying to work on the issue
<https://gitlab.com/mailman/mailman/issues/385>.
I've been unable to make a test fail. I finally discovered that when I
run 'tox -e py35-nocov-mysql' or 'tox -e py35-nocov-mysql -- -P hold',
tox installs the pymysql dependency, but SQLAlchemy is still using the
sqlite dialect when the tests run.
It appears I may need a [database] section in some mailman.cfg, but I
don't know what I would put there for accessing the database, and I
don't know where I'd put the .cfg.
Also, isn't this something tox should just do?
I do think that when GitLab CI runs the mysql tests it does actually use
mysql as I've seen mysql related failures there, but I don't seem to
have the magic to make it work locally.
--
Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers,
San Francisco Bay Area, California better use your sense - B. Dylan
I'm in favor of dropping Python2. All distros have Python3 and afaik all
dependencies are Python3 ready. So I don't see a reason why anybody
would want to stick to Python2, especially since core is Python3 only...
Hi All,
Mailman uses Django web framework for the web based frontends, Postorius
- The Official UI, and Hyperkitty - The official Archiver. They are both
Django "apps" which means that they can be plugged into any other
existing Django "project" (aka Django "installation") to work alongside
other apps that people might be running.
Currently, both the Django apps we have are Python 2 only, we have
talked about moving to Python 3 but we decided we want it to be
bilingual (support both 2 & 3). The reason we decided that was because
if people would want to embed Postorius & Hyperkitty in their
installations, they need to be able to run it under whatever python
versions they are using.
I want to revisit this assumption for being bilingual. Currently, there
is no supported version of Django which doesn't support Python 3.
Starting from v2.0, set to release in December 2017, Django is going to
drop Python2 support. Now, that doesn't mean no one can run Django under
Python2, 1.11 (LTS version) supports Python2 and will be supported
probably till Python 2 is supported (April 2020 according to [1]).
I believe that our (limited) development efforts would be best utilized
if we just drop the support for Python 2 in Postorius & Hyperkitty
instead of trying to be bilingual. Any day one of our dependencies may
decide to do the same, and we would have to then use Python 3 anyway.
Also, dropping Python 2 support doesn't seem like a lot of pain for
anyone, you just need another instance of Django running, which is not
*that* hard using uwsgi (in Emperor mode). I believe most of our
dependencies should support Python 3, or should have a good enough
replacement if it doesn't.
Thoughts?
[1]: https://www.djangoproject.com/download/
--
Abhilash Raj
maxking(a)asynchronous.in