4 ms·

Yes, I did try to comprehend the NMG, but didn't ask for anyones help. But AFAIR, back then (mid 2015), the python specific parts of the packaging manuals were

Yes, I did try to comprehend the NMG, but didn't ask for anyones help. But AFAIR, back then (mid 2015), the python specific parts of the packaging manuals were scattered between some presentations and loose documentation here and there. Thanks for the link though. I might get back to it. Still, I believe that a robust system like debian could be achieved by more simpler means. It's packaging system is an invention of a different era and needs more streamlining to accommodate dynamic language developers. Python was invented in 90's and it's took 20+ years for debian to setup some serious guidelines for python developers. What if I want to package a software written in another dynamic language which was invented a month ago? These questions need to be addressed. Disclaimer: I am not claiming that I could device a solution. Just that, despite my best intentions and best of efforts, I couldn't handle the difficulty of packaging.

mmt 8y ago
> Python was invented in 90's and it's took 20+ years for debian to setup some serious guidelines for python developers. I've only ever packaged in-house (within a company I'm working for) Python apps, very simple opern-source apps and libraries and modified existing packaging for new versions of such open source code that otherwise already had available packaging [1], but my experience has been different to the point that I disagree [2]. Since I'm a sysadmin and not a developer, my strategy was not just to use the documentation, but also to look at how other packages handled certain situations, especially if I knew of an app that was relatively complicated in terms of build process. For Python, that was mostly a challenge of unravelling each developer's build/install instructions (easy_install/setup.py/pip) into something that matched an existing debianized Python package. > Still, I believe that a robust system like debian could be achieved by more simpler means. It's packaging system is an invention of a different era and needs more streamlining to accommodate dynamic language developers. As a sysadmin, I object to the characterization of the debian package system as being "of a different era", mostly because I don't believe there's anything about this era, nor about dynamic languages (which have been around for a very long time anyway) that has eliminated the needs that it addresses. That robustness is achieved because of the requirement of up-front effort to conform to a standard that has remained stable across eras. > What if I want to package a software written in another dynamic language which was invented a month ago? Same as for every other language since the beginning of time: put in the effort (including asking for help from the community) and conform. If you need a language-specific standard (such as the OS-default for egg-equivalents), then make one up (consistent with other languages) and get your new language's community behind it, if that's possible. Of course, the other option is just to exist exclusively within that language's ecosystem (e.g. pip, gem, cpan) and wait for other interested parties to do the OS-level packaging for you. That happens, too, but it can slow adoption if your "market" is production environments and not just other devs in the ecosystem. [1] Although sometimes with inadequate/inaccurate "debianization" (e.g. missing expicitly listing a depency) [2] I do agree that the documentation isn't necessarily organized in the best fashion, nor that the latest info is in one place, but it's out there. There might also not be One True Way, but it's arguable if that's a bad thing.

mmt 8y ago

> Python was invented in 90's and it's took 20+ years for debian to setup some serious guidelines for python developers. I've only ever packaged in-house (within a company I'm working for) Python apps, very simple opern-source apps and libraries and modified existing packaging for new versions of such open source code that otherwise already had available packaging [1], but my experience has been different to the point that I disagree [2]. Since I'm a sysadmin and not a developer, my strategy was not just to use the documentation, but also to look at how other packages handled certain situations, especially if I knew of an app that was relatively complicated in terms of build process. For Python, that was mostly a challenge of unravelling each developer's build/install instructions (easy_install/setup.py/pip) into something that matched an existing debianized Python package. > Still, I believe that a robust system like debian could be achieved by more simpler means. It's packaging system is an invention of a different era and needs more streamlining to accommodate dynamic language developers. As a sysadmin, I object to the characterization of the debian package system as being "of a different era", mostly because I don't believe there's anything about this era, nor about dynamic languages (which have been around for a very long time anyway) that has eliminated the needs that it addresses. That robustness is achieved because of the requirement of up-front effort to conform to a standard that has remained stable across eras. > What if I want to package a software written in another dynamic language which was invented a month ago? Same as for every other language since the beginning of time: put in the effort (including asking for help from the community) and conform. If you need a language-specific standard (such as the OS-default for egg-equivalents), then make one up (consistent with other languages) and get your new language's community behind it, if that's possible. Of course, the other option is just to exist exclusively within that language's ecosystem (e.g. pip, gem, cpan) and wait for other interested parties to do the OS-level packaging for you. That happens, too, but it can slow adoption if your "market" is production environments and not just other devs in the ecosystem. [1] Although sometimes with inadequate/inaccurate "debianization" (e.g. missing expicitly listing a depency) [2] I do agree that the documentation isn't necessarily organized in the best fashion, nor that the latest info is in one place, but it's out there. There might also not be One True Way, but it's arguable if that's a bad thing.