Bug#758402: ITP: python-xstatic-jquery.quicksearch -- jQuery.quicksearch XStatic support
Package: wnpp Severity: wishlist Owner: Thomas Goirand * Package name: python-xstatic-jquery.quicksearch Version : 2.0.4.1 Upstream Author : Radomir Dopieralski * URL : https://github.com/stackforge/xstatic-jquery.quicksearch * License : Expat Programming Lang: Python Description : jQuery.quicksearch XStatic support 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. . Many Python projects need to use some specific data files, like javascript, css, java applets, images, etc. 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. 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. . 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. . This package provides jQuery.quicksearch support as a Python module. -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140817075631.931.43808.report...@buzig.gplhost.com
Bug#758402: ITP: python-xstatic-jquery.quicksearch -- jQuery.quicksearch XStatic support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Thomas, If you’re going to introduce many similar packages in the archive, may I recommend a proofread of the common description by d-l-english, CCed? Among ugly things that strikes me as odd: - - weird upper case emphasis (e.g., YOUR, MINIMAL); - - incorrect upstream reference (e.g., s/javascript/JavaScript/;s/java/Java/;s/js/JavaScript/;s/linux/Linux/;s/bsd/BSD/;s/windows/Windows/) Some parts may be of little relevance for a Debian package too: > 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. Thanks in advance for considering. Regards David Le 17/08/2014 03:56, Thomas Goirand a écrit : > Package: wnpp > Severity: wishlist > Owner: Thomas Goirand > > * Package name: python-xstatic-jquery.quicksearch > Version : 2.0.4.1 > Upstream Author : Radomir Dopieralski > * URL : https://github.com/stackforge/xstatic-jquery.quicksearch > * License : Expat > Programming Lang: Python > Description : jQuery.quicksearch XStatic support > > 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. > . > Many Python projects need to use some specific data files, like javascript, > css, java applets, images, etc. 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. 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. > . > 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. > . > This package provides jQuery.quicksearch support as a Python module. > > -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBCAAGBQJT8KleAAoJEAWMHPlE9r08z00H/i/JWHPiJEr62m5zh3HZqmKc V9+Yf8LwntZRDgkweDXgE3inNEc7cXaBj6nKuWnLWEkRWCoL0OVkUq6EVlZsrNMp Kuci78RD28I/7BiLw5WTNtrKdX92vwI4T0YTVRMaBTeOGx07mwT51/+QxCFpwNlF uOYL83lDCvFJcBM3KtV+rLUsOsTJxptB5K2OApVyft2btml2CRKsNWMehdeeaO6l Tl3goswTd4ODfH9S+9rP3a5IBtPYfB66FN3U92cSw50N5UmhQf+HZHtUXHkxLpTv CD+3rzM2NUYnZNaIehGti+MV/1UBXs2MtTNbtwENo7/A6MJbv+shHB/n84GQpdY= =jb6v -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f0a95e.2050...@tilapin.org
Bug#758402: ITP: python-xstatic-jquery.quicksearch -- jQuery.quicksearch XStatic support
Hi David, Thanks for this message. I would welcome indeed any change to this long description, reviewed by the d-l-english team! On 08/17/2014 09:08 PM, David Prévot wrote: > Hi Thomas, > > If you’re going to introduce many similar packages in the archive, may I > recommend a proofread of the common description by d-l-english, CCed? > > Among ugly things that strikes me as odd: > - weird upper case emphasis (e.g., YOUR, MINIMAL); > - incorrect upstream reference (e.g., > s/javascript/JavaScript/;s/java/Java/;s/js/JavaScript/;s/linux/Linux/;s/bsd/BSD/;s/windows/Windows/) These are copy/past from the upstream stuff, but as it is often the case, it shall be improved. > Some parts may be of little relevance for a Debian package too: >> 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. I do believe this is relevant. The point of the XStatic packages is that they are available using "pip install", which make them universal. This is a very good "selling point" for Python developers, and will push them to use XStatic rather than embedding static files directly in their python module/app. Of course, this can be changed to something like "it is also easier to build virtual envs, which will work in any distribution" if you think that's more relevant. Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f0b91c.5060...@debian.org
Bug#758402: ITP: python-xstatic-jquery.quicksearch -- jQuery.quicksearch XStatic support
Thomas Goirand wrote: > Thanks for this message. I would welcome indeed any change to this long > description, reviewed by the d-l-english team! Well, I'd like to, but so far I don't really understand it. I don't even know what it means by "static files". As opposed to what? > These are copy/past from the upstream stuff, but as it is often the > case, it shall be improved. > >> Some parts may be of little relevance for a Debian package too: >>> 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. > > I do believe this is relevant. The point of the XStatic packages is that > they are available using "pip install", which make them universal. This > is a very good "selling point" for Python developers, and will push them > to use XStatic rather than embedding static files directly in their > python module/app. I'm sure it's an interesting fact about XStatic, and therefore may belong in the package description for python-xstatic. But how is it useful information for people trying to decide whether to install python-xstatic-jquery.quicksearch? It seems to amount to "this software is also available as something that isn't a Debian package", and that's true of pretty much anything in the archives. Meanwhile there's literally no description whatsoever of the functionality of jQuery.quicksearch! -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140817142921.ga6...@xibalba.demon.co.uk
Bug#758402: ITP: python-xstatic-jquery.quicksearch -- jQuery.quicksearch XStatic support
I think I'm getting closer to understanding, but not close enough. David Prévot wrote: >> * Package name: python-xstatic-jquery.quicksearch [...] >> Description : jQuery.quicksearch XStatic support >> >> 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. Okay, a bit of research tells me there's a chunk of context missing here: it's taking it for granted that I already know it's talking specifically about web development where the part you're coding is in Python but it depends on other people's JavaScript (or similar). I would probably have understood that quicker if I was a developer, but still, it's friendlier to the people reading this if the information that tells them "this isn't for you" is at the start. Some further googling reveals that by "static files", Python web developers mean the kind of data files you might expect to find under $DOCROOT/resources/ or somewhere. "Static" files as opposed to... I'm not sure what. Dynamically generated pages? User-provided content? Oh well; maybe we can get away with using the word "static" and hoping that readers somehow already know what it means. That seems to be what everyone else is doing. And the point of XStatic is that you want to incorporate some particular "static files" into your $DOCROOT/resources directory, but... well, maybe the nature of the problem will become clear later. But I definitely don't yet understand how XStatic renders a collection of files "easily usable on all operating systems with any package management system". Sure, bundling files into a Python egg might make them accessible via a Python egg installer, but that's not the same thing as making it possible to install them with APT. >> . >> Many Python projects need to use some specific data files, like javascript, >> css, java applets, images, etc. 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. I can't believe it needs to spend so much effort explaining the case where there isn't a problem for this software to solve. Should "jQuery javascript library" have an article? So the thing to do is arrange for the package that contains your Python software to depend on the package that contains that JavaScript library. Right? Oh, no, of course, you can't do that because you're not on Debian, so your packaged Python doesn't have any way of depending on JavaScript - other than directly including the files, which is nasty. Or... putting them in a *fake* Python package? Aaah! Maybe this is beginning to make sense now... >> So, you want to have static file packages, but you >> don’t want to get lots of stuff you do not want. The stuff I don't want to get is the stuff I do not want? What a coincidence! Or perhaps a really turgid explanation. >> Thus, stuff required by >> XStatic file packages (especially the main, toplevel XStatic package) tries >> to >> obey to be a MINIMAL, no-fat thing. "To obey to be" is the only part of this that's out-and-out ungrammatical. "Stuff tries to be a thing." This paragraph is overstuffed. >> 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. I like the air of mystery - maybe there will be optional extensions for stuff, or maybe there won't! But not only will they be optional, they won't be required. >> . >> By having static files in packages, it is also easier to build virtual envs, Borderline ungrammatical. And isn't it "virtualenvs"? (Or "virtual environments", but that's bad because it sounds as if it means what it says.) >> support linux/bsd/... distribution package maintainers and even windows >> installs using the same mechanism. All the above is the blurb for the XStatic framework, and doesn't belong in the python-xstatic-jquery.quicksearch package description unless that Debian package really does make it easier to support Windows installs. A deverbosified version could go in the package description for python-xstatic, but I'd prefer to start from somewhere else. The python-xstatic-* packages should have a much, much shorter section saying something like XStatic (see python-xstatic) is a Python web development tool for bundling sets of required data files from external non-Python projects into Python p
Bug#758402: ITP: python-xstatic-jquery.quicksearch -- jQuery.quicksearch XStatic support
On 08/17/2014 10:29 PM, Justin B Rye wrote: > Thomas Goirand wrote: >> Thanks for this message. I would welcome indeed any change to this long >> description, reviewed by the d-l-english team! > > Well, I'd like to, but so far I don't really understand it. I don't > even know what it means by "static files". As opposed to what? As opposed to dynamic content. For example: - javascript - .css - .png are all static files, and not scripts. This is what XStatic provides. >> I do believe this is relevant. The point of the XStatic packages is that >> they are available using "pip install", which make them universal. This >> is a very good "selling point" for Python developers, and will push them >> to use XStatic rather than embedding static files directly in their >> python module/app. > > I'm sure it's an interesting fact about XStatic, and therefore may > belong in the package description for python-xstatic. But how is it > useful information for people trying to decide whether to install > python-xstatic-jquery.quicksearch? It seems to amount to "this > software is also available as something that isn't a Debian package", > and that's true of pretty much anything in the archives. The point is that they will have an API to find out what is the location of the jquery.quicksearch in the system. And this API will work on every operating system using packages (if they are available), or by downloading the XStatic package using "pip install xstatic-jquery.quicksearch" within the Python virtualenv. > Meanwhile there's literally no description whatsoever of the > functionality of jQuery.quicksearch! The package depends on libjs-quicksearch. This is where you have the correct description, and that's where I expect users will read. Do you think the description of jquery.quicksearch should be copied there too? By the way, python-xstatic-* packages aren't directly useful for the final users, they will only be dependencies of Python applications, and in my case, the OpenStack dashboard (eg: the Horizon web GUI). On 08/18/2014 06:26 AM, Justin B Rye wrote: > Some further googling reveals that by "static files", Python web > developers mean the kind of data files you might expect to find under > $DOCROOT/resources/ or somewhere. >From Debian's perspective, the files would be in /usr/share/. > "Static" files as opposed to... I'm not sure what. Dynamically > generated pages? Yes. Often Django based web interface (as we're in Python). FYI Django is *the* Python web GUI framework everyone is using, though I don't think XStatic is specific to Django itself. > But I definitely don't yet understand how XStatic renders a collection > of files "easily usable on all operating systems with any package > management system". Sure, bundling files into a Python egg might make > them accessible via a Python egg installer, but that's not the same > thing as making it possible to install them with APT. The point of XStatic is to avoid developers to embed static files of libraries (often: javascript libraries) directly in their Python application, which is a security disaster from a distribution stand point. A Python developer will simply make his application "require" (which is the Python language to say "depends") the XStatic python module. If the developer works with pip, then it will automatically "pip install xstatic-jquery.quicksearch" for example, which will go in the virtualenv (which is a kind of chroot-like stuff specific to Python, if you like). When in a distribution like Debian, the python-xstatic-jquery.quicksearch does *not* embed the library. It only Depends: on the libjs-jquery.quicksearch (which I packaged separately), and "points" to it (eg: in the package, I have patched upstream code "BASE_DIR" configuration variable, which is what upstream recommends). So XStatic stuff are really made for better integration within distributions. > So the thing to do is arrange for the package that contains your > Python software to depend on the package that contains that JavaScript > library. Right? Oh, no, of course, you can't do that because you're > not on Debian, so your packaged Python doesn't have any way of > depending on JavaScript - other than directly including the files, > which is nasty. Or... putting them in a *fake* Python package? Aaah! > Maybe this is beginning to make sense now... I think you got it! Except that it's not really a "fake" python package, it's a real one which is available from PyPi... :) So, these Python packages really include the javascript, though the Debian resulting python .deb will not. >> By having static files in packages, it is also easier to build >> virtual envs, > > Borderline ungrammatical. And isn't it "virtualenvs"? (Or "virtual > environments", but that's bad because it sounds as if it means what it > says.) virtual envs, or virtualenvs, are in the common Python dictionary. This should stay as-is. Anyone who knows a bit about Python knows (or heard about)
Bug#758402: ITP: python-xstatic-jquery.quicksearch -- jQuery.quicksearch XStatic support
Thomas Goirand wrote: > On 08/17/2014 10:29 PM, Justin B Rye wrote: >> Thomas Goirand wrote: >>> Thanks for this message. I would welcome indeed any change to this long >>> description, reviewed by the d-l-english team! >> >> Well, I'd like to, but so far I don't really understand it. I don't >> even know what it means by "static files". As opposed to what? > > 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/! >>> I do believe this is relevant. The point of the XStatic packages is that >>> they are available using "pip install", which make them universal. This >>> is a very good "selling point" for Python developers, and will push them >>> to use XStatic rather than embedding static files directly in their >>> python module/app. >> >> I'm sure it's an interesting fact about XStatic, and therefore may >> belong in the package description for python-xstatic. But how is it >> useful information for people trying to decide whether to install >> python-xstatic-jquery.quicksearch? It seems to amount to "this >> software is also available as something that isn't a Debian package", >> and that's true of pretty much anything in the archives. > > The point is that they will have an API to find out what is the location > of the jquery.quicksearch in the system. And this API will work on every > operating system using packages (if they are available), or by > downloading the XStatic package using "pip install > xstatic-jquery.quicksearch" within the Python virtualenv. Yes, this explains why my imaginary developer on BeOS would want it - or even developers on Debian who want to work entirely in Python eggs and bypass APT. But it doesn't quite explain why there's a Debian package. >> Meanwhile there's literally no description whatsoever of the >> functionality of jQuery.quicksearch! > > The package depends on libjs-quicksearch. This is where you have the > correct description, and that's where I expect users will read. Do you > think the description of jquery.quicksearch should be copied there too? Seeing it as a sort of dependency shim package, maybe you could cut the entire thing right down to: This package integrates jQuery.quicksearch (see libjs-quicksearch) into the XStatic system (see python-xstatic). > By the way, python-xstatic-* packages aren't directly useful for the > final users, they will only be dependencies of Python applications, and > in my case, the OpenStack dashboard (eg: the Horizon web GUI). Well, the final users of webapps might not even own a computer! But for the sake of Debian users scanning the list of newly available devel packages, the ideal description would let them see at a glance whether this is useful to them. [...] >> But I definitely don't yet understand how XStatic renders a collection >> of files "easily usable on all operating systems with any package >> management system". Sure, bundling files into a Python egg might make >> them accessible via a Python egg installer, but that's not the same >> thing as making it possible to install them with APT. > > The point of XStatic is to avoid developers to embed static files of > libraries (often: javascript libraries) directly in their Python > application, which is a security disaster from a distribution stand > point. A Python developer will simply make his application "require" > (which is the Python language to say "depends") the XStatic python > module. If the developer works with pip, then it will automatically "pip > install xstatic-jquery.quicksearch" for example, which will go in the > virtualenv (which is a kind of chroot-like stuff specific to Python, if > you like). Yes, so developers using pip get to pull in Python xstatic-foo modules as dependencies. I see that. But requiring xstatic-foo can't pull in a Debian package; and if on the other hand I'm using Debian package dependencies, what's the benefit of depending on python-xstatic-foo instead of libjs-foo direct? Does python-xstatic-foo maybe set up the libjs-foo libraries so that they're pulled into a virtualenv (for some reason) instead of being used directly out of the system libraries? No, apparently not... Oh, no, I see: even if pip can't *pull in* a .deb, a previously installed .deb might still contain the module in an appropriate way to satisfy the dependency. Perhaps even for people running pip within a virtualenv? > When in a distribution like Debian, the > python-xstatic-jquery.quicksearch does *not* embed the library. It only > Depends: on the libjs-jquery.quicksearch (which I packaged separately), > and "points"
Bug#758402: ITP: python-xstatic-jquery.quicksearch -- jQuery.quicksearch XStatic support
On 08/18/2014 11:00 PM, 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. Thomas -- To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f30b91.9000...@debian.org
Bug#758402: ITP: python-xstatic-jquery.quicksearch -- jQuery.quicksearch XStatic support
On 08/18/2014 11:00 PM, Justin B Rye wrote:
> Yes, this explains why my imaginary developer on BeOS would want it -
> or even developers on Debian who want to work entirely in Python eggs
> and bypass APT. But it doesn't quite explain why there's a Debian
> package.
Well, because that's one of the dependency of a Python app I am packaging.
> Yes, so developers using pip get to pull in Python xstatic-foo modules
> as dependencies. I see that. But requiring xstatic-foo can't pull in
> a Debian package; and if on the other hand I'm using Debian package
> dependencies, what's the benefit of depending on python-xstatic-foo
> instead of libjs-foo direct?
The package python-xstatic-foo contains the necessary logic to tell your
application where foo is in your Debian system. That way, your Python
application will work in both environment in the same way. In both cases
(eg: "pip install / virtual env", or using Debian package), it will use
the XStatic system to search for a particular static file. In the
virtual env, it will use the file embedded in the XStatic package (as
downloaded from PyPi), but in Debian, it will use what
python-xstatic-foo configures, which is access to the files of libjs-foo.
> Does python-xstatic-foo maybe set up the libjs-foo libraries so that
> they're pulled into a virtualenv (for some reason) instead of being
> used directly out of the system libraries?
No. But it provides the path to /usr/share/javascript/foo to the Python
application who will load/use/serve it.
> Oh, no, I see: even if pip can't *pull in* a .deb, a previously
> installed .deb might still contain the module in an appropriate way to
> satisfy the dependency. Perhaps even for people running pip within a
> virtualenv?
For people using pip & virtualenv, then it will use the embedded static
file contained in the package served by pypi.python.org.
> 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.
Author: Thomas Goirand
Forwarded: not-needed
Last-Update: 2014-08-17
---
python-xstatic-jquery.quicksearch-2.0.4.1.orig/xstatic/pkg/jquery_quicksearch/__init__.py
+++
python-xstatic-jquery.quicksearch-2.0.4.1/xstatic/pkg/jquery_quicksearch/__init__.py
@@ -11,7 +11,7 @@ NAME = __name__.split('.')[-1] # package
# please use a all-lowercase valid python
# package name
-VERSION = '2.0.3' # version of the packaged files, please use the upstream
+VERSION = '2.0.4' # version of the packaged files, please use the upstream
# version number
BUILD = '1' # our package build number, so we can release new builds
# with fixes for xstatic stuff.
@@ -34,9 +34,9 @@ HOMEPAGE = 'http://plugins.jquery.com/jq
LICENSE = '(same as %s)' % DISPLAY_NAME
from os.path import join, dirname
-BASE_DIR = join(dirname(__file__), 'data')
+#BASE_DIR = join(dirname(__file__), 'data')
# linux package maintainers just can point to their file locations like
this:
-#BASE_DIR = '/usr/share/javascript/jquery_quicksearch'
+BASE_DIR = '/usr/share/javascript/jquery.quicksearch'
LOCATIONS = {
# CDN locations (if no public CDN exists, use an empty dict)
Do you get it now? :)
>> I hope now that everything make sense, and that you can write back a
>> single new reply so that we can close this case! :)
>
> 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. Debian packages are orthogonal to virtualenv, there's no
hook, even though a Debian package will satisfy the pip dependency. In a
virtualenv, typically, you'd use the packages from PyPi, not from
Debian, and this could work on all systems (including BeOS ?). In such
case, you'd use the static files from the PyPi package, not the system one.
So, a developer may use PyPi and "pip install", in which case we don't
care (he does what he wants in his virtualenv in MacOS or whatever). But
in Debian, we care not to use embedded files, so we have
python-xstatic-foo which depends: libjs-foo, and points to the files in
/usr/share/javscript/foo so that the application of that same developer
will use the system version of foo, rather than the embedded static
files of xstatic-foo, as served by PyPi.
Let me know if things still need to be clarified.
Thomas Goirand (zigo)
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53f30b42.6090...@debian.org
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 pa
