Bug#758402: ITP: python-xstatic-jquery.quicksearch -- jQuery.quicksearch XStatic support
Thomas Goirand wrote:
>> If I can work out the final wrinkle ("why would you Debianise it?")
>> then I might add a couple of words, but that would be more or less it.
>
> # cat debian/patches/debianize.patch
> Description: Debianize the package
> Using files from libjs-jquery.quicksearch instead of embedded files.
Actually the word "embedded" might be worth putting somewhere in the
description for python-xstatic.
>> Let's see: the Debian package can't be pulled in by pip, but it can
>> satisfy pip dependencies, which improves portability in aspects of the
>> workflow I probably don't need to know about.
>
> Correct.
>
>> If it also provides
>> hooks to make virtualenv setups work more smoothly
>
> Not correct.
Oh, well, then probably there's no need to add anything more to the
python-xstatic-foo descriptions; leave them as
This package integrates jQuery.quicksearch (see libjs-quicksearch)
into the XStatic system (see python-xstatic).
or
$XSTATIC_BOILERPLATE_PARA
.
This package integrates jQuery.quicksearch (see libjs-quicksearch)
into the XStatic system.
Going back to the longer version for python-xstatic itself: I had
XStatic (see python-xstatic) is a Python web development tool for
bundling sets of required data files from external non-Python
projects into Python packages that your app can depend on portably.
but lets see if there's anything extra that needs to be kept from the
long version...
> XStatic is a packaging standard to package external (often 3rd party) static
> files as a Python package, so they are easily usable on all operating systems,
> with any package management system or even without one.
Well, I have to keep the word "static" somewhere.
> .
> Many Python projects need to use some specific data files, like javascript,
> css, java applets, images, etc.
Mention a couple of these examples.
Sometimes these files belong to YOUR project
> (then you may want to package them separately, but you could also just put
> them into your main package). But in many other cases, those files are
> maintained by someone else (like jQuery javascript library or even much bigger
> js libraries or applications) and you definitely do not really want to merge
> them into your project.
Mention avoiding embedded copies.
> So, you want to have static file packages, but you
> don’t want to get lots of stuff you do not want. Thus, stuff required by
> XStatic file packages (especially the main, toplevel XStatic package) tries to
> obey to be a MINIMAL, no-fat thing. XStatic doesn't "sell" any web framework
> or other stuff you don't want. Maybe there will be optional XStatic extensions
> for all sorts of stuff, but they won't be required if you just want the files.
Probably boils down to the word "simple" or "lightweight".
> .
> By having static files in packages, it is also easier to build virtual envs,
> support linux/bsd/... distribution package maintainers and even windows
> installs using the same mechanism.
The word "virtualenv" should probably still be there.
Are XStatic packages enough like Debian dependency packages that we
should use that term, or would that just confuse people? I'll avoid
it for now.
XStatic is a Python web development tool for handling required static
data files from external projects, such as CSS, images, and JavaScript.
It provides a lightweight infrastructure to manage them via Python
modules that your app can depend on in a portable, virtualenv-friendly
way instead of using embedded copies.
Meanwhile in another e-mail Thomas Goirand wrote:
> Justin B Rye wrote:
>>> As opposed to dynamic content. For example:
>>>> - javascript
>>>> - .css
>>>> - .png
>>>>
>>>> are all static files, and not scripts. This is what XStatic provides.
>>
>> When you say "not scripts" you mean "not the Python code of your
>> actual webapp", right? Oh well, I get it now. My confusion was
>> because when a package description says it contains "static files",
>> that essentially boils down to "any actual files at all", since
>> obviously it can't provide content for $DOCROOT/dynamic/!
>
> You should view a javascript file just as if it was a PNG image... This
> is still static content, which will *not* be modified grammatically in
> the Python application.
Being literally static as opposed to dynamic has little to do with it.
The Python code is just as static as the JavaScript, but you call the
JavaScript "static" because it's web developer jargon for an external
resource. All resources borrowed from external sources are
necessarily static; but not all static files are resources borrowed
from external sources.
The hardest parts of developer jargon to understand are always the
parts that the developers assume are transparent!
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: