Re: Preconditions for python-moto finished - help needed to build package itself
Hi Lumin, On Tue, Feb 06, 2018 at 03:27:22PM +, Lumin wrote: > With patch [1] dpkg-buildpackage can go a bit further while building > this package. > See requirements-dev.txt. And new problems arose: I've added python-flask to Build-Depends and can reproduce this issue: > 1. $ make test # python2 > > ImportError: No module named vendored I've found a hint to this issue here https://github.com/boto/boto/issues/3222 but it claims that the issue was dealt with in version python-boto-2.38.0. Since we have 2.44.0 I assume we are facing a different problem. > 2. $ make test_server # python2 > > ConnectionError: HTTPConnectionPool(host='localhost', port=5000): Max > retries exceeded with url: Hope thas is fixed by python-flask Build-Depends. > 3. $ nosetests3 -sv --with-coverage --cover-html ./tests/ > > ModuleNotFoundError: No module named 'botocore.vendored' > AttributeError: module 'botocore' has no attribute 'vendored' > > It seems that the "vendored" is from botocore package. I'm not > sure which package or script to blame. Further investigation needed. Yes. Unfortunately I can not spent any time on this for the next couple of days. > I don't know whether it helps to add all the dependencies specified by > requirements-dev.txt to control. I guess its promising to check this list. I'd be happy if somebody would beat me in doing so. ;-) Kind regards Andreas. -- http://fam-tille.de
Re: Move to salsa? Merge modules and apps team?
[Ole Streicher, 2018-02-07] > Piotr Ożarowski 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
Re: Move to salsa? Merge modules and apps team?
Piotr Ożarowski 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? > 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. The rules for both are (should be) the same, right? So, what is the difference? Best regards Ole
Re: Move to salsa? Merge modules and apps team?
Hello, On Wed, 07 Feb 2018, W. Martin Borgert wrote: > how about moving the Python team(s) to salsa? Definitely! But we might want to learn from the perl team to structure the python-team: https://lists.debian.org/debian-perl/2018/01/msg00039.html We could then have everything python related in the same team but with different sub-groups for modules, applications and interpreter. > Moving git packages (modules team) is very easy using > import.sh from https://salsa.debian.org/mehdi/salsa-scripts.git I used those scripts with a small loop to migrate pkg-security and it worked fine. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: Merge modules and apps team?
On 2018-02-07 09:58, Matthias Klose wrote: > I don't think that is a good idea. Both teams are not very active when it > comes > to address RC issues and updating to new upstream versions. From my point of > view the apps team is worse than the modules team in this regard. In fact, this is one of the reasons I like to merge them. I hope, that the slightly better situation of the modules will rub off on the apps. My illusions might be in vain, but at least I do not see any disadvantage in the merge.
Re: Move to salsa? Merge modules and apps team?
[W. Martin Borgert, 2018-02-07] > how about moving the Python team(s) to salsa? that's the natural place to move from alioth for both teams. PAPT's repos will also have to be converted from svn to git. All we need is a volunteer who will prepare it and supervise the process. > 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. 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. The only advantage I can see is less hassle with join requests, but I don't think it's a big problem (you have to join once). I also have a feeling the more packages (team members?) we have, the less people care about packages without their name in Maintainer/Uploaders fields (even those who did team-wide changes in the past are not so active now, including myself) and the team name should be changed to collab-maint-2 or collab-maint-py. > Moving git packages (modules team) is very easy using > import.sh from https://salsa.debian.org/mehdi/salsa-scripts.git looks like it takes only one repo at a time -- GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Re: Move to salsa? Merge modules and apps team?
On 07.02.2018 10:12, Ghislain Vaillant wrote: > 2018-02-07 8:58 GMT+00:00 Matthias Klose : >> On 07.02.2018 08:37, W. Martin Borgert wrote: >>> Hi, >>> >>> how about moving the Python team(s) to salsa? >>> And how about merging the modules and apps teams into one? >>> >>> Moving git packages (modules team) is very easy using >>> import.sh from https://salsa.debian.org/mehdi/salsa-scripts.git >>> >>> Moving svn packages (apps team) is probably more work. >>> >>> Any opinions? Any doubts? >> >> I don't think that is a good idea. Both teams are not very active when it >> comes >> to address RC issues and updating to new upstream versions. > > How does that affect moving our hosting to salsa? Or is your point > against merging both teams? I am confused. > >> From my point of >> view the apps team is worse than the modules team in this regard. Currently >> both teams really don't care about packages which are uploaded by other team >> members. Maybe it's time to clean up the teams before any considerations to >> merge them? For single maintainers we do have process for MIA, and for QA >> uploads, however both python teams are escaping such efforts. > > Still unclear what all of this has to do with the salsa migration. I > understand your concerns, but imo they are orthogonal to the > transition. no, it's about merging the teams, not the move to the new infrastructure.
Re: Move to salsa? Merge modules and apps team?
2018-02-07 8:58 GMT+00:00 Matthias Klose : > On 07.02.2018 08:37, W. Martin Borgert wrote: >> Hi, >> >> how about moving the Python team(s) to salsa? >> And how about merging the modules and apps teams into one? >> >> Moving git packages (modules team) is very easy using >> import.sh from https://salsa.debian.org/mehdi/salsa-scripts.git >> >> Moving svn packages (apps team) is probably more work. >> >> Any opinions? Any doubts? > > I don't think that is a good idea. Both teams are not very active when it > comes > to address RC issues and updating to new upstream versions. How does that affect moving our hosting to salsa? Or is your point against merging both teams? I am confused. > From my point of > view the apps team is worse than the modules team in this regard. Currently > both teams really don't care about packages which are uploaded by other team > members. Maybe it's time to clean up the teams before any considerations to > merge them? For single maintainers we do have process for MIA, and for QA > uploads, however both python teams are escaping such efforts. Still unclear what all of this has to do with the salsa migration. I understand your concerns, but imo they are orthogonal to the transition. Cheers, Ghis
Re: Move to salsa? Merge modules and apps team?
On 07.02.2018 08:37, W. Martin Borgert wrote: > Hi, > > how about moving the Python team(s) to salsa? > And how about merging the modules and apps teams into one? > > Moving git packages (modules team) is very easy using > import.sh from https://salsa.debian.org/mehdi/salsa-scripts.git > > Moving svn packages (apps team) is probably more work. > > Any opinions? Any doubts? I don't think that is a good idea. Both teams are not very active when it comes to address RC issues and updating to new upstream versions. From my point of view the apps team is worse than the modules team in this regard. Currently both teams really don't care about packages which are uploaded by other team members. Maybe it's time to clean up the teams before any considerations to merge them? For single maintainers we do have process for MIA, and for QA uploads, however both python teams are escaping such efforts. Matthias
Re: Move to salsa? Merge modules and apps team?
Hi, 2018-02-07 8:37 GMT+01:00 W. Martin Borgert : > how about moving the Python team(s) to salsa? > +1 > And how about merging the modules and apps teams into one? > +1 > Moving git packages (modules team) is very easy using > import.sh from https://salsa.debian.org/mehdi/salsa-scripts.git I think we can migrate all git-based packages (all DPMT) at once Moving svn packages (apps team) is probably more work. > and do this in second step. -- Best regards Ondřej Nový Email: n...@ondrej.org PGP: 3D98 3C52 EB85 980C 46A5 6090 3573 1255 9D1E 064B
Re: Move to salsa? Merge modules and apps team?
Le 7 févr. 2018 07:38, "W. Martin Borgert" a écrit : Hi, how about moving the Python team(s) to salsa? I'd be in favour for that. And how about merging the modules and apps teams into one? Same here. A single Python Team (python-team in salsa) would make sense. Moving git packages (modules team) is very easy using import.sh from https://salsa.debian.org/mehdi/salsa-scripts.git Moving svn packages (apps team) is probably more work. Could the import be done in stages then? Imo, packages which are ready for transition should not have to wait. Any opinions? Any doubts? TIA & Cheers