[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Remove thingiview.

From: Ben Sturmfels
Subject: Re: Remove thingiview.
Date: Fri, 23 Apr 2021 16:18:43 +1000
User-agent: mu4e 1.4.15; emacs 27.2

Hi jgart,

>> Thanks for the patch! I'm sorry that I've given you the wrong impression
>> here - the aim is not literally to delete thingiview and leaflet, but
>> rather just not to include them in the Guix packaging. 
> What are your thoughts for not including that javascript in the guix package?
> Here's are small list to clarify/elaborate my thinking on it:
> 1. I'm not sure if guix upstream would accept a service that has
> unused javascript files being referenced in its master branch. It
> might be good to ask about that just to make sure.
> 2. Guix upstream is hoping we present them with less javascript files
> that get installed to /gnu/store

I think we should remove any unused bundled JavaScript during the guix
build. I'm working on some updates to the Guix channel to do this.

> 3. If the javascript files are unused why would we want to keep them
> in the master branch that is presented to guix upstream instead of
> just archiving them in a branch or tag for perusal? It would be easier
> to remove them from master and put them in another branch or tag.
> Otherwise, we'll have to delete those unused bundled javascript files
> programatically with guile in the guix package that runs in
> production. This will increase the amount of code that we have to
> write in the guix package.
> 4. We could always view the archived javascript files by visiting a
> previous commit or perusing them in a separate branch or tag.

Guix is only one of deployment option for MediaGoblin. These JS files
are used if you deploy according to our deployment guide, so removing
them would unnecessarily remove features for non-Guix users.

>> The challenge will be figuring out how best to add jquery,
>> video.js and videojs-resolution-switcher to the Guix package when they
>> normally come from NPM.
> We would add the unminified but concatenated jquery and videojs
> sources as assets in the same way that cuirass does.
> If we could not depend on videojs in the future that would be great
> for reducing the size. Videojs has alot of direct dependencies to
> manage compared to jquery. See the issue opened here:

Yes, I think that's the approach we'll need to use for jquery and
videojs. We may be able to reduce our dependence on videojs in the
future - browser support has improved significantly over the years.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]