Re: Uploading python-xstatic-* packages in Debian
On 08/15/2014 12:28 AM, Jonas Smedegaard wrote: Quoting Thomas Goirand (2014-08-14 09:26:05) Note that the XStatic python modules aren't just meta packages, they also offer a mechanism for a Python script to discover where to find a given static file in the system (which really, isn't obvious, as the Debian archive is a bit messy in this regard, especially when dealing with static files that aren't javascript like .css or .less files). You are quite welcome to propose tp relevant teams streamlining which could ease your packaging. A cleanup might take time to coordinate, and agreeing on tidying the structure may take time too, but that shouldn't discourage you from initiating that process :-) I recommend to discuss that in those smaller teams rather than here. Well, unfortunately, I'm not sure there's a solution, or at least, I don't have it. Things are the way they are because upstream decided to put this or that file in this or that folder, and then every upstream has his own convention. Then we just follow upstream, and that is a good thing. But at the end, we end up with no convention. A more broad standard should, at some point, be establish, so that everyone (and by this, I mean also upstream authors...) sorts files in the same way. Anyway, this was just a few thoughts, I didn't intend to start a troll thread about this. :) For some XStatic packages, the embedded static files are not present in Debian. That is the case for example with python-xstatic-hogan, python-xstatic-jasmine, or python-xstatic-bootstrap-scss. For the above 3 packages, the upstream source code is part of a much larger project. Please don't embed reusable non-Python code into Python-specific packages - then you end up with same problem as you ran into yourself with ruby-bootstrap-sass (see right below). Instead, package (or request others like the Javascript ot Sass team) to package those which you need. I'm doing the libjs-* packages whenever that's not too big, and manageable by myself. I did that for libjs-twitter-bootstrap-datepicker for example, then I just depend on that package. See for example bootstrap-scss, which comes with a huge Ruby framework. I have no intention to package all of that... I guess you mean ruby-bootstrap-sass - please see bug#739783. Oh, swt! What I need is in compass-bootstrap-sass-plugin :) Thanks a lot for the pointer, Jonas. This is really helpful. Indeed, #739783 is important to be fixed for me as well, as I wont be using ruby at all, and I don't think it's reasonable to get 10MB of non-useful ruby stuff for Horizon ! :) As I know very little about packaging of some upstream code (for example, I have never maintained ruby or nodejs packages), and that I don't need them anyway (I only need a few javascript files from them, I will have no use of Ruby or nodejs code), then I decided to *not* package the full upstream package, and leave the embedded copy inside the python-xstatic-* packages. This is until someone needs the full upstream package, at which point I will remove the embedded copy, and point to the relevant files inside the recently uploaded package. Please don't postpone proper packaging until others eventually steps up. Theoretically, you are right. Unfortunately, this isn't practical. I'm sorry, but I just can't package stuff that I have no use for, or for which I have no knowledge (ruby is a good example of this). This will be bad work, and I don't want to upload crap which I wont even be able to check by myself. It would also sometimes be too much work, for which I wont have time for. I also don't believe that just writing an RFP will make it happen. If this was the case, I'd just do that, always, and stop doing any sort of packaging myself... So, I'm going to do this only as much as I can, when possible. I hope you'll understand. Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53edb61c.7050...@debian.org
Re: Uploading python-xstatic-* packages in Debian
Quoting Thomas Goirand (2014-08-15 09:26:20) On 08/15/2014 12:28 AM, Jonas Smedegaard wrote: Quoting Thomas Goirand (2014-08-14 09:26:05) Note that the XStatic python modules aren't just meta packages, they also offer a mechanism for a Python script to discover where to find a given static file in the system (which really, isn't obvious, as the Debian archive is a bit messy in this regard, especially when dealing with static files that aren't javascript like .css or .less files). You are quite welcome to propose tp relevant teams streamlining which could ease your packaging. A cleanup might take time to coordinate, and agreeing on tidying the structure may take time too, but that shouldn't discourage you from initiating that process :-) I recommend to discuss that in those smaller teams rather than here. Well, unfortunately, I'm not sure there's a solution, or at least, I don't have it. I don't expect you to have solutions, only - maybe - ideas. That s exactly why I suggest doing it as teamwork :-) Please don't embed reusable non-Python code into Python-specific packages - then you end up with same problem as you ran into yourself with ruby-bootstrap-sass (see right below). Instead, package (or request others like the Javascript ot Sass team) to package those which you need. [...] Please don't postpone proper packaging until others eventually steps up. Theoretically, you are right. Unfortunately, this isn't practical. I'm sorry, but I just can't package stuff that I have no use for, or for which I have no knowledge (ruby is a good example of this). This will be bad work, and I don't want to upload crap which I wont even be able to check by myself. It would also sometimes be too much work, for which I wont have time for. I also don't believe that just writing an RFP will make it happen. If this was the case, I'd just do that, always, and stop doing any sort of packaging myself... So, I'm going to do this only as much as I can, when possible. I hope you'll understand. What I suggest is that you package stuff you have no use for, nor that you just write RFPs. What I suggest is that you collaborate with teams. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Uploading python-xstatic-* packages in Debian
On Thu, 14 Aug 2014, Thomas Goirand wrote:
What would probably work better would be to add the python library
inside upstream code.
That would work as well.
But then we have another issue: the Python module is supposed to be
packaged as python-something, and the JS libs are supposed to be
packaged as libjs-something. So we'd have to break one or the other
convention.
No. Provides exist for a reason.
I don't think that's desirable to do. We don't want to break automatic
dependency calculation by dh_python{2,3} either.
You can add those to the libjs-* source packages.
The important bit is that upstream requires version X of
python-xstatic-jquery because it needs version X of jquery. When we have
That is *even more* reason to merge the packaging of the
xstatic things with the packaging of the libraries they
provide!
The XStatic package itself doesn't contain much but the Python
wrapper, so it's not a big deal (it's very simplistic Python code).
That’s a good argument in favour of integrating the python
side into the Debian packages of the upstreams of the xstatic
packages.
static files libraries. In fact, XStatic has been created upstream with
distributions in mind, and I find it very nice of them. It's indeed
solving the problem, even if that's some non-negligible work at first to
do the python-xstatic-* packaging.
That doesn’t mean we have to implement the API the same way.
Integrating something into the libjs-* packages to provide
xstatic would also fulfil that, and use the very nice thing
upstream made, just not the same way to there.
bye,
//mirabilos
--
[16:04:33] bkix: veni vidi violini
[16:04:45] bkix: ich kam, sah und vergeigte...
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/alpine.deb.2.11.1408151115370.23...@tglase.lan.tarent.de
Re: Uploading python-xstatic-* packages in Debian
On Thu, 14 Aug 2014, Thomas Goirand wrote: Just a quick explanation of what I'm doing with the python-xstatic-* packages here. I've thought about how to do it best for a long time. Thanks! I was wondering. It is also worth noting that the Debian package version for XStatic modules is following the static file package version. For example, even though upstream released XStatic-JQuery 1.10.2.1, the Debian package version is 1.7.2.0, to match the version number of libjs-jquery. Idea here: can’t python-xstatic-jquery just take over libjs-jquery via Provides, so we have one binary package less after this? (Of course, if the Debian JS maintainers agree, and probably will want to (co-)maintain python-xstatic-jquery after this.) Similar for the other ones. That would mean we’d have almost zero cost for the addi‐ tion of python-xstatic-* because they’d just take over the non-xstatic ones and provide the same functionality plus more. My only concern with all of this, is that it will produce a lot of micro-packages. Though I believe the benefits of having a clean system to remove embedded copies and having a clean way to find these files on a Debian system outweighs the added load on our infrastructure. Right… which is why I suggested the above ;-) As for micro packages in general… I’d say the goal here is to remove code duplication, so packaging things like this is useful, but if there are several micro packages with the same dependencies, they could be grouped into one binary package, for example this was done in src:mediawiki-extensions which produces mediawiki-extensions-base for all those with no additional dependencies, and then several small packages that contain only one or two extensions each, which share some additional dependencies like PHP modules, graphviz, etc. Since we can have versioned Provides soon, I believe this could be used by most of the JS packages. A binary package libjs-jquery-bundle which Provides all the others with versions. This would leave us with the maintainer burden because it has multiple upstreams with different versions. Simply adding the version numbers will not always sort well, either… but I think that the overall load (maintainers + infrastructure + mirrors + users) will be the lowest like that. bye, //mirabilos PS: [OT] A coworker just shared this in our MUC: https://lh3.googleusercontent.com/-bZId5j2jREQ/U-vlysklvCI/CrA/B4JggkVJi38/w426-h284/bd0fb252416206158627fb0b1bff9b4779dca13f.gif -- [16:04:33] bkix: veni vidi violini [16:04:45] bkix: ich kam, sah und vergeigte... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/alpine.deb.2.11.1408140934140.30...@tglase.lan.tarent.de
Re: Uploading python-xstatic-* packages in Debian
On 14 Aug 2014 17:43, Thorsten Glaser t...@debian.org wrote: It is also worth noting that the Debian package version for XStatic modules is following the static file package version. For example, even though upstream released XStatic-JQuery 1.10.2.1, the Debian package version is 1.7.2.0, to match the version number of libjs-jquery. Finding it hard to understand the reasoning here. Idea here: can’t python-xstatic-jquery just take over libjs-jquery via Provides, so we have one binary package less after this? (Of course, if the Debian JS maintainers agree, and probably will want to (co-)maintain python-xstatic-jquery after this.) Similar for the other ones. That would mean we’d have almost zero cost for the addi‐ tion of python-xstatic-* because they’d just take over the non-xstatic ones and provide the same functionality plus more. In what way will python-xstatic-jquery be better than libjs-jquery? Still trying to understand this. Thanks
Re: Uploading python-xstatic-* packages in Debian
Brian May dixit: In what way will python-xstatic-jquery be better than libjs-jquery? No. What I meant is: | Package: python-xstatic-jquery | Provides: libjs-jquery is better than | Package: python-xstatic-jquery | Depends: libjs-jquery | | Package: libjs-jquery because it’s less packages. bye, //mirabilos -- Yay for having to rewrite other people's Bash scripts because bash suddenly stopped supporting the bash extensions they make use of -- Tonnerre Lombard in #nosec -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/pine.bsm.4.64l.1408141218310.11...@herc.mirbsd.org
Re: Uploading python-xstatic-* packages in Debian
On 08/14/2014 03:43 PM, Thorsten Glaser wrote:
Idea here: can’t python-xstatic-jquery just take over libjs-jquery
via Provides, so we have one binary package less after this? (Of
course, if the Debian JS maintainers agree, and probably will want
to (co-)maintain python-xstatic-jquery after this.) Similar for the
other ones. That would mean we’d have almost zero cost for the addi‐
tion of python-xstatic-* because they’d just take over the non-xstatic
ones and provide the same functionality plus more.
Well, the xstatic packages don't contain the full upstream source, they
mostly contain the javascript file (eg: jquery.js in this case), and
that's it. Upstream for jquery has lots of other stuff included.
What would probably work better would be to add the python library
inside upstream code. But then we have another issue: the Python module
is supposed to be packaged as python-something, and the JS libs are
supposed to be packaged as libjs-something. So we'd have to break one
or the other convention. I don't think that's desirable to do. We don't
want to break automatic dependency calculation by dh_python{2,3} either.
On 08/14/2014 07:02 PM, Brian May wrote:
It is also worth noting that the Debian package version for XStatic
modules is following the static file package version. For example,
even though upstream released XStatic-JQuery 1.10.2.1, the Debian
package version is 1.7.2.0, to match the version number of
libjs-jquery.
Finding it hard to understand the reasoning here.
The important bit is that upstream requires version X of
python-xstatic-jquery because it needs version X of jquery. When we have
jquery 1.7.2, then we just add a leading version number for the
python-xstatic-jquery package, and it becomes 1.7.2.0. The XStatic
package itself doesn't contain much but the Python wrapper, so it's not
a big deal (it's very simplistic Python code).
On 08/14/2014 07:02 PM, Brian May wrote:
In what way will python-xstatic-jquery be better than libjs-jquery?
It's not in any way better, it just adds the Python wrapper layer, so
upstream code can easily find out that jquery is located in
/usr/share/javascript/jquery. As for upstream, they mostly use
virtualenv stuff, downloading from PyPi to run the unit tests, and in
that case, the XStatic package will contain the jquery.js /
jquery.min.js file. So it's transparent for upstream, and provides us
(eg: distribution package maintainers) a way to stop having embedded
static files libraries. In fact, XStatic has been created upstream with
distributions in mind, and I find it very nice of them. It's indeed
solving the problem, even if that's some non-negligible work at first to
do the python-xstatic-* packaging.
For reference, have a look at this, it may be better than all of my
explanations:
https://github.com/stackforge/xstatic-angular/blob/master/xstatic/pkg/angular/__init__.py
In Debian, I just patch VERSION =, and BASE_DIR=. That's in fact what
upstream for XStatic expects me to do! Then on the resulting package, I
just delete the xstatic/pkg/angular/data folder and its content which
contains the embedded Angular javascript files, since I want to use
/usr/share/javascript/angular.js instead.
I hope that's better explanations. If not, ping me again...
Thomas
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53eccb61.7000...@debian.org
Re: Uploading python-xstatic-* packages in Debian
On 14/08/14 15:44, Thomas Goirand wrote: On 08/14/2014 07:02 PM, Brian May wrote: In what way will python-xstatic-jquery be better than libjs-jquery? It's not in any way better, it just adds the Python wrapper layer, so upstream code can easily find out that jquery is located in /usr/share/javascript/jquery. As for upstream, they mostly use virtualenv stuff, downloading from PyPi to run the unit tests, and in that case, the XStatic package will contain the jquery.js / jquery.min.js file. So it's transparent for upstream, and provides us (eg: distribution package maintainers) a way to stop having embedded static files libraries. In fact, XStatic has been created upstream with distributions in mind, and I find it very nice of them. It's indeed solving the problem, even if that's some non-negligible work at first to do the python-xstatic-* packaging. I can't help thinking that this is a lot like pkg-config, but runtime instead of compile-time, and specific to Python instead of biased towards C/C++. If the XStatic files are pure metadata (albeit in Python syntax and installed to the PYTHONPATH, because when all you have in some of your target OSs/environments is a Python hammer, everything looks like a nail), wouldn't it make more sense to ask the various Javascript projects' upstreams to ship them? After all, when libwhatever doesn't ship whatever.pc, we don't upload pkg-config-whatever.deb, we file a wishlist bug against libwhatever please include a .pc file. S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53ecd812.4070...@debian.org
Re: Uploading python-xstatic-* packages in Debian
Quoting Thomas Goirand (2014-08-14 09:26:05) Note that the XStatic python modules aren't just meta packages, they also offer a mechanism for a Python script to discover where to find a given static file in the system (which really, isn't obvious, as the Debian archive is a bit messy in this regard, especially when dealing with static files that aren't javascript like .css or .less files). You are quite welcome to propose tp relevant teams streamlining which could ease your packaging. A cleanup might take time to coordinate, and agreeing on tidying the structure may take time too, but that shouldn't discourage you from initiating that process :-) I recommend to discuss that in those smaller teams rather than here. For some XStatic packages, the embedded static files are not present in Debian. That is the case for example with python-xstatic-hogan, python-xstatic-jasmine, or python-xstatic-bootstrap-scss. For the above 3 packages, the upstream source code is part of a much larger project. Please don't embed reusable non-Python code into Python-specific packages - then you end up with same problem as you ran into yourself with ruby-bootstrap-sass (see right below). Instead, package (or request others like the Javascript ot Sass team) to package those which you need. See for example bootstrap-scss, which comes with a huge Ruby framework. I have no intention to package all of that... I guess you mean ruby-bootstrap-sass - please see bug#739783. As I know very little about packaging of some upstream code (for example, I have never maintained ruby or nodejs packages), and that I don't need them anyway (I only need a few javascript files from them, I will have no use of Ruby or nodejs code), then I decided to *not* package the full upstream package, and leave the embedded copy inside the python-xstatic-* packages. This is until someone needs the full upstream package, at which point I will remove the embedded copy, and point to the relevant files inside the recently uploaded package. Please don't postpone proper packaging until others eventually steps up. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Uploading python-xstatic-* packages in Debian
On 08/14/2014 11:38 PM, Simon McVittie wrote: If the XStatic files are pure metadata (albeit in Python syntax and installed to the PYTHONPATH, because when all you have in some of your target OSs/environments is a Python hammer, everything looks like a nail), wouldn't it make more sense to ask the various Javascript projects' upstreams to ship them? It will still produce another binary package, so it doesn't solve the problem of avoiding that. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53ece5bc.4090...@debian.org
