[Ole Streicher, 2018-02-07] > Piotr Ożarowski <pi...@debian.org> writes: > > [W. Martin Borgert, 2018-02-07] > >> And how about merging the modules and apps teams into one? > > > > I don't understand this, though. Why you want to merge them? > > Sure, packaging Python applications is very similar to packaging > > libraries but the difference is very significant - unfortunately many > > application maintainers don't know or care about it and pollute global > > Python namespace with private libraries. > > So, why would you like to keep them separate?
Could you start with why do you want to merge them first? If there are no advantages, why change? > > If not separated at team level, I definitely want to have them somehow > > separated at repository level so that it's clear which package is which > > type or to easily checkout libraries only. > > At least in the field where I package (astronomy), this does not work: > many of our packages are libraries *and* apps. Often they come as a big > (public) library with a small startup wrapper, and it is a matter of > taste (and of how deep an astronomer digs into Python) whether it is > used from the shell or from a Jupyter notebook. well, if your application provides public library, it's a library to me to be honest. It has to be taken care of in each transition and so on so an additional tiny script in /usr/bin doesn't matter (I even install such scripts in python*-foo binary packages) > The rules for both are (should be) the same, right? So, what is the > difference? the difference is you install an application in private dir and care about default Python change only (less work for us, less disk space, less buildd time, etc.) and less problems with conflicting names (why would you bother searching for an unique name for a private lib?). If you want to write a script that checks something in all of team packages, it's easier if you can assume all of them are libraries. -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645