[Mailman-Developers] Re: How strict are the dependencies on the django-compressor related backends?
Hey again, Jonas Meurer: > I finally found some time to look into this. > > * Hyperkitty doesn't need (or use) less.js/lessc at all. It can safely > be removed from COMPRESS_PRECOMPILERS. I've now done this in the Debian mailman3-web package and hope to get this into Buster before release. > * The situation is different with sassc, it's actually used for > compressing CSS by hyperkitty. Doing the compression at build-time > should be possible but requires more work. I have a plan ;) For that, I now also have a working implementation as well. Due to the change being rather invasive, I will not push this into Buster though. And my plan slightly changed during implementing it, see below ;) >> I was wondering if we could by default not install >> node-less/ruby-sass and what exactly that would imply. >> >> @Jonas M.: what do you think about [2] (again maybe after Buster)? >> Sorry to not know more of this yet, but I hope suggesting what I think >> might work helps to get us the right way. > > I'm absolutely in favour of getting rid of the sassc runtime dependency. > After a chat with Jonas Smedegaard (thanks for his valuable input!), I > think that I have an idea and a roadmap on how to get there: > > 1. Process `static/hyperkittysass/hyperkitty.scss` with sassc at build- >time and patch `templates/hyperkitty/base.html` to reference the >resulting CSS file. That's what I did now, and it already was enough to drop the build-time dependency on sassc. Django-compressor is still used to combine several CSS and JS files into one by running 'django-admin compress' in the postinst script of mailman3-web, but since the source files are already clean CSS and JS, no external processors (like sassc or lessc) are required. I think this is perfectly fine and I don't see much benefit in combining the CSS and JS files at build-time. It would allow to drop the django-compressor dependency but with the cost of more heavy build-time adjustments that need to be maintained in future. So I'm happy to now have a solution to drop both node-less and sassc from runtime dependencies in the Debian package. Thanks to everyone for their input on this topic. I added a comment to upstream hyperkitty issue #120 where I proposed to do the same in the upstream hyperkitty release process and that way get rid of the sassc runtime dependency: https://gitlab.com/mailman/hyperkitty/issues/120#note_179256370 Cheers jonas signature.asc Description: OpenPGP digital signature ___ Mailman-Developers mailing list -- mailman-developers@python.org To unsubscribe send an email to mailman-developers-le...@python.org https://mail.python.org/mailman3/lists/mailman-developers.python.org/ Mailman FAQ: https://wiki.list.org/x/AgA3 Security Policy: https://wiki.list.org/x/QIA9
[Mailman-Developers] Re: Integration of SMS alerts for moderator approval
sandeep kumar writes: > For every mail notification that is sent to moderator for approval he > should also receive the SMS on his mobile saying so and so list is pending > for approval. > This is the requirement of the customer. For the future, you don't have to explain why you want a feature until we ask for it. > For SMS the message will be shortened form say "mail to X list from Y > person is pending for your approval". Yeah, of course this needs to be shorter. This could be parsed from the normal mail by the SMS gateway, or some kind of front end to the gateway. > When I mean by SMS gateway it is nothing but a SMS service that we are > already using for other purposes. We give an input to the SMS server with > phone number and message it will send the SMS to user. My question is what form is this input, email or something else? > I need to fetch the moderator email address of every list when an email is > sent to list. I am facing some challenges here in getting the moderator > email address. Can you please help where in the mailman code can I get the > moderator email address when a mail is sent to the list. I guess you're trying write such a front-end yourself. It depends on how you are going to access the database. Mark explained how to do this directly. Alternatively, you can create the frontend client as an external process, using the mailmanclient library to access the REST API to get that information. I think this is what Mark suggested, and it's the preferred method because it means you do not have to maintain a vendored version of Mailman itself. The REST API is versioned, so you can be sure that your code either works right or it fails loudly. The internal API is not versioned and not going to be backward compatible, so you risk having your code break every time you upgrade. You'd still need to have a small Handler to trigger the external frontend, but everything you need for the trigger is already in the message object (the mailing list's identity), and that part of the internal API is extremely unlikely to change. Steve ___ Mailman-Developers mailing list -- mailman-developers@python.org To unsubscribe send an email to mailman-developers-le...@python.org https://mail.python.org/mailman3/lists/mailman-developers.python.org/ Mailman FAQ: https://wiki.list.org/x/AgA3 Security Policy: https://wiki.list.org/x/QIA9
[Mailman-Developers] Re: How strict are the dependencies on the django-compressor related backends?
[I've put the related Debian bugreport in the loop] Hello, I finally found some time to look into this. Disclaimer: I don't know much about CSS compression and the mailman3 web interface is the first time that I got into contact with either of sassc and node-less. TL;DR: * Hyperkitty doesn't need (or use) less.js/lessc at all. It can safely be removed from COMPRESS_PRECOMPILERS. * The situation is different with sassc, it's actually used for compressing CSS by hyperkitty. Doing the compression at build-time should be possible but requires more work. I have a plan ;) Christian Ehrhardt: > I have checked a fully installed mailman3 stack in Debian/Ubuntu and > there are only two sources of .less files that we have to be concerned > of. > > First there is the package fonts-font-awesome which is pulled in on > the following path: > [...] > It seems different for the second case which is libjs-bootstrap from > the source package twitter-bootstrap3 I don't think that any of the .less files you're referencing to will be processed by 'django-admin compress' on the mailman3-web project. The .less files are all outside the scope of the mailman3-web project. So I'm pretty sure that the node-less/lessc dependency can safely be dropped immediately. Moreover, looking at the hyperkitty example_project/settings.py[1], it doesn't even reference the lessc compiler at all. Only settings.py from mailman-suite[2] references it, which probably is a copy-and-paste bug. There's even an open issue about that[3]. Since in Debian we took the mailman-suite settings.py as template, we suffer from this copy-and-paste bug as well. [1] https://gitlab.com/mailman/hyperkitty/blob/master/example_project/settings.py#L315-317 [2] https://gitlab.com/mailman/mailman-suite/blob/master/mailman-suite_project/settings.py#L359-362 [3] https://gitlab.com/mailman/mailman-suite/issues/7 > Does anyone know of other uses of .less in the mailman3 stack that I > have missed that we would have to think about? Regarding sassc: Hyperkitty is the only part of the mailman3 stack that uses django-compressor. And apparently there's just one single html template that will be processed by sassc (well, to be precise, all html files that use this template): /usr/lib/python3/dist-packages/hyperkitty/templates/hyperkitty/base.html In this file, four CSS files are being compressed and packed together by sassc: hyperkitty/libs/fonts/icomoon/icomoon.css hyperkitty/libs/fonts/droid/droid.css django-mailman3/css/main.css hyperkitty/sass/hyperkitty.scss The last one is special as it's a scss file itself and needs to be processed by sassc itself. > OTOH there also is an experimental approach to this, could someone > with a dev-stack of mailman3 just remove the node-less package and see > if on a normal setup something breaks at all? I've done this. Result: removing node-less doesn't change anything (which is in line with my assumption that node-less/less.js/lessc is not required/used at all). On the other hand, removing sassc breaks the setup, even with COMPRESS_OFFLINE being turned on: CommandError: An error occurred during rendering /usr/lib/python3/dist-packages/django_mailman3/templates/django_mailman3/profile/delete_profile.html: /bin/sh: 1: sassc: not found Christian Ehrhardt: > On Fri, Mar 15, 2019 at 10:19 AM Jonas Smedegaard wrote: >> >> Quoting Christian Ehrhardt (2019-03-15 06:39:08) >>> On Fri, Mar 15, 2019 at 12:08 AM Abhilash Raj >>> wrote: On Thu, Mar 14, 2019, at 1:42 PM, Jonas Meurer wrote: Christian Ehrhardt: > I was evaluating the Dependencies of mailman3 in Ubuntu and I was > wondering if I could cut them down a bit. One thing that got my > attention is the dependency from mailman3-web [1] to nodejs for > less [2] and ruby-sass [3]. > > I was wondering if we could by default not install > node-less/ruby-sass and what exactly that would imply. >> >> less is a reinvention of sass: It is often adaptable to sass with a >> simple patch. >> >> Original sass processor was ruby-sass, but nowadays a better processor >> is sassc. Or if you want to integrated processing with Python then >> python3-libsass which uses same core library for its processing. >> >> I have not looked closely on mailman3, but I highly doubt there is a >> real need for dynamic processing of less/sass during runtime. > > Yeah I doubt that as well. > In the meantime I also found [1] which seems to have come to the same > conclusion for the majority of default setups. > For upstream to disable it by default it was mentioned that there is a > need for a customize kit which seems fine [1]. > > There is a further argument to disable the live compressors, at least > as I read COMPRESS_OFFLINE that seems helpful for production setups > anyway to speed up and safe CPU load. You're totally right. Therefore, COMPRESS_OFFLINE is already enabled per default in mailman3-web on Debian. The django-admin compress command is executed duri
