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

Re: django-ajax-selects lintian errors/warnings



On Mon, 30 Nov 2015 20:41:15 +1100
Brian May <bam@debian.org> wrote:

> Neil Williams <codehelp@debian.org> writes:
> 
> > So the reference to bootstrap.js needs to be patched out to refer
> > to a static location which can be put in place using a Depends in
> > debian/rules.  
> 
> Still trying to work out how this could work. What path should I put
> in bootstrap.js?
> 
> STATIC_URL is configured by the application that uses
> django-ajax-selects. We have no idea what it might be set to. So we
> cannot hardcode any path into bootstrap.js

Then the reference needs to be inserted by a templatetag which knows
about the running configuration.

> Also, bootstrap.js is also a static file, so we cannot use
> {{ STATIC_URL }} here.

If it's also a static file, that's exactly what {{ STATIC_URL }}
provides. It's a static file owned by django-ajax-selects, so
{{ STATIC_URL }} is correct within d-a-s and the file just gets replaced
by a symlink to the min.js of the external package during install. The
URL is the .min.js but the editable .js is provided in VCS.
 
> > Isn't bootstrap.js doing that already? If bootstrap.js is part of
> > upstream, using bootstrap.js brings in an external jquery.  
> 
> bootstrap.js is a NOP if jquery and jquery-ui has already been loaded
> by the application.

Sounds like there needs to be some clarification here. What I'm
expecting is something like this:

0: blah.js lives in the django-ajax-select VCS, upstream.

1: javascript.py is configured to convert that to a symlink to
the .min.js from an external package or to uglify the VCS version into
a .min.js and remove the .js from the django-ajax-select binary
package. This happens at build time of django-ajax-select so that
security fixes to blah.js can be applied as Debian patches to
django-ajax-select with the assurance that changes to the .js do get
carried into the .min.js that every dependency actually uses. If
d-a-s does the uglify, then d-a-s is in sole control of where
that .min.js can be found.

2: Apps using django-ajax-select can call a templatetag (which lives
in the d-a-s python code) to get the location of the .min.js installed
by django-ajax-select (whether that's a symlink or not) or can be left
to do their own setup of finding it. As a file installed by d-a-s, it's
quite possible that apps which are packaged for Debian would simply put
the installed location into their own configuration of javascript.py in
their own source code. In that sense, d-a-s is no different to
libjs-blah which puts a .min.js into /usr/share/ - apps can simply list
that in their own configuration for javascript.py. If using a
templatetag, the templatetag can be generic for the d-a-s location,
independent of what {{ STATIC_URL }} says within the app using d-a-s.
Any logic about whether to reference it or not either goes into the
dependency app or the templatetag. Overall, it's simpler to just get
dependencies to use their own javascript.py config.

> 
> > I provided links for scripts which do exactly this last time, these:
> >
> > https://git.linaro.org/lava/lava-server.git/blob/HEAD:/share/javascript.py
> > https://git.linaro.org/lava/lava-server.git/blob/HEAD:/share/javascript.yaml  
> 
> What calls javascript.py? Is it somehow called by setup.py?

https://github.com/Linaro/pkg-lava-server/blob/master/debian/rules#L55

setup.py isn't useful here - it barely knows how to do the install of
the files in the first place, let alone actually implementing logic
during the install.

-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

Attachment: pgpv528Egk5kY.pgp
Description: OpenPGP digital signature


Reply to: