Re: Switching to git
Vincent Bernat wrote: > Hi! > > There was some discussions about switching from SVN to git. I don't > remember everything but a major blocker was that it is not possible to > checkout a subtree with git and managing a lot of git repositories will > make it difficult to do global changes to the "global" repository. > > There is currently a discussion in debian-devel about how to switch from > SVN to git and they seem to use "mr". For what is worth, I am in favor of switching to git, as I am already using git-svn locally, with regular dcommit's. What was done in the pkg-kde team was (AFAIK) a progressive migration in the "who wants to migrate his package can do so" style, with a documented process (namespaces, content of the leftover README in the svn, …). And it worked pretty well. With enough mind's flexibility, it's totally workeable. (But in the end I don't really care what the VCS is [as long as there's a git-$foo tool available :-p ]). Cheers, OdyX -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/il248q$ugp$1...@dough.gmane.org
Re: shebang lines for Python scripts
> It's also unnecessary for distros because we should know exactly which version > of Python our scripts work with. And finally, setuptools will rewrite the > shebang line when it installs scripts (FSVO 'setuptools' ;). FTR, that’s actually done by the distutils build_scripts command. Relevant extract from the docs: Scripts don’t require Distutils to do anything very complicated. The only clever feature is that if the first line of the script starts with #! and contains the word “python”, the Distutils will adjust the first line to refer to the current interpreter location. By default, it is replaced with the current interpreter location. The --executable (or -e) option will allow the interpreter path to be explicitly overridden. http://docs.python.org/dev/distutils/setupscript#installing-scripts (A bit of missing info in the doc: The --executable option is on the build and build_scripts command.) Regards -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d749db2.6050...@netwok.org
Re: Switching to git
On Sun, Mar 06, 2011 at 05:30:15PM -0500, Yaroslav Halchenko wrote: > > Wouldn't managing python packages with mercurial make sense? > > it would as much as with any other DVCS, such as GIT. I am yet to hear > any objective advantage for using Python-based DVCS because they are > written in Python to maintain python packages Being a maintainer of Python packages often means you know Python which enables you to make mercurial work the way want: write a plugin, write a script that looks for information in the repo, etc. from mercurial import hg, ui repo = hg.repository(ui.ui(), dirname) changed = repo.status() # do something with changed... This proved *very* valuable over the years to get things done very quickly when working with a large number of mercurial repositories and was much faster than writing bash scripts that run the hg command. Now, I heard the argument about being the user of a DVCS rather than hacking that DVCS, I do not intend to fight against the large amount of people that know git (a majority maybe?), want git to be used everywhere (some would like to have hg used everywhere, don't they) and do not want to learn hg (it is true that comparing the two can take a bit of one's time, because they are so similar). Doesn't matter, I'll use http://hg-git.github.com/ if I need to ;) -- Nicolas Chauvat logilab.fr - services en informatique scientifique et gestion de connaissances -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110307101942.ga4...@volans.logilab.fr
Re: Switching to git
Hi Steve,
On Sun, 06.03.2011 at 14:18:40 -0800, Steve Langasek wrote:
> AIUI Scott is talking here about the ease of transitioning an svn user to
> bzr because of the similarity of the command model, not about using either
> git or bzr to access the current svn repo.
I was talking about the robustness of using an SVN repository. With
bzr, it just works, and with git... it works, too (maybe).
At least, I get a reproducible problem downloading roundup's SVN repo
with git, where it breaks somewhere in the middle. Oh, and hg also
threw up badly, afair. This is what I sent to the roundup-dev at the
end of 2009, when "they" had a similar discussion:
rsync'ing the SVN repo: very good
bzr-svn: very good
git-svn: ok (crashes every 1000 revisions)
using svn directly against the SF repo: bad (dog slow)
hg-convert: very bad (didn't complete yet from the SF repo, several
connection resets from SF)
"very good" means that it worked in one go, and with acceptable
performance.
> Do you mean the fact that branches each require a separate directory, rather
> than being collocated in a single directory the way git's are?
This is one thing, yes. Also, the bzr way, I can easily lose the
corellation between any two branches because they just don't know
about each other. For me, the ability to switch branches in-place is
also a big win, at least with our current setup (which is hard to
change).
> I don't know why you would say that merging is more difficult in bzr,
> frankly. Perhaps you're comparing bzr merging with the seemingly common git
> practice of discarding revision history as a substitute for doing an actual
> DVCS merge? Having done merges in both systems, I don't see any major
> differences.
I've _often_ run into the situation that merging was just impossible
("... branches have diverged..." and similar messages, where I was just
stuck and had to manually transplant the changes from one branch to the
other, thus _definitely_ losing all history of the other branch.
Maybe it's only me, but although I find git difficult to learn at the
beginning, it didn't yet give me such blockers "down the road".
--
Kind regards,
--Toni++
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110307112348.23306.qm...@oak.oeko.net
Re: Switching to git
On Mar 07, 2011, at 08:18 AM, Bernd Zeimetz wrote: >On 03/06/2011 07:33 PM, Barry Warsaw wrote: >> On Mar 06, 2011, at 05:43 PM, Sandro Tosi wrote: >> >>> Do the 2 VCDs you mentioned have clear advantage that make then >>> preferible to git except being Python-based? If so, I think it's a >>> quite weak reason. >> >> Let me turn that around: why would you *not* want to use a Python based dVCS? > >Because none is as advanced as git is. Are there specific git features that you think the team would want to use, that are missing from the other dvcs? -Barry signature.asc Description: PGP signature
Bug#617272: transition: python3-defaults
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition It looks like we are ready to switch the default python3 in Unstable from 3.1 to 3.2. It should affect a relatively small number of packages. Source uploads needed: distribute python3-pkg-resources distribute python3-setuptools python-distutils-extra python3-distutils-extra python3-lxmlpython3-lxml BinNMU: gearman-interfacepython3-gearman.libgearman jinja2 python3-jinja2 lxml python3-lxml py-postgresqlpython3-postgresql python-apt python3-apt python-bsddb3python3-bsddb3 python-drizzle python3-drizzle pyyaml python3-yaml sip4 python3-sip -- System Information: Debian Release: squeeze/sid APT prefers maverick-updates APT policy: (500, 'maverick-updates'), (500, 'maverick-security'), (500, 'maverick-backports'), (500, 'maverick') Architecture: i386 (i686) Kernel: Linux 2.6.35-27-generic (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110307175510.32711.98540.reportbug@localhost6.localdomain6
GPL applications using Python (OpenSSL issue?)
Can GPLv3+ applications written in Python exist in Debian main? The applications in question do not use an openssl exception. Python uses OpenSSL so the moment the application starts, it is linking against it too: $ objdump -p /usr/bin/python2.6 | grep NEEDED NEEDED libpthread.so.0 NEEDED libdl.so.2 NEEDED libutil.so.1 NEEDED libssl.so.0.9.8 NEEDED libcrypto.so.0.9.8 NEEDED libz.so.1 NEEDED libm.so.6 NEEDED libc.so.6 In my case I am talking about a GPLv3+ package that exists in Debian -- kupfer Where do I draw the line for using/linking against ssl? a) Using Python2.6 b) Unintentionally introducing _ssl or ssl into the imported modules (import any of urllib, httplib, socket etc!) c) Unintentionally using ssl (use urllib.urlopen on URL provided by user -- if it's https we are using openssl) d) Intentionally using ssl (import ssl and use httplib.HTTPSConnection and verify certificates) Kupfer is today at (c) in the debian archive. It exists in development version at (d). Clearly (d) has provoked thought but upon investigation I see that "import ssl" only triggers "import _ssl" which in turn is an almost no-op because _ssl is a built-in module in Python 2.6. Is this easier to answer than I think it is? Ulrik -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktik0qlvls_1ugcwbzeu3skmbfxzmeuf6na8p1...@mail.gmail.com
Re: managing toplevel __init__.py files
Hi,
thanks for the links.
My results are even more humple:
https://launchpad.net/~pythonxy
https://launchpad.net/~pythonxy/+archive/individual-devel
https://launchpad.net/~pythonxy/+archive/individual-releases
https://launchpad.net/~pythonxy/+archive/metapackages
Many things could be optimised.
But it is a start.
Regards,
Timmie
>> i have started to package a series of modules for scipy.
>> These are put on the namespace as
>> scikits.timeseries
>> scikits.statsmodels
>
>> etc.
>
> ah cool --
> $> wnpp-check statsmodels
> python-scikits-statsmodels (RFP - #570604)
>
> if of any help, my packaging which was rejected solely due to missing
> copyrights on some data files (if those are copyrightable at all), so
> you might want to look at
>
> http://git.debian.org/?p=pkg-exppsy/statsmodels.git
>
>> trying to overwrite
>> '/usr/lib/python2.6/site-packages/scikits/__init__.py', which is also in
>> package python-scikits-timeseries 0.91.3-2~ppa5
>
> packages should not ship those -- pysupport iirc would create it
> properly
>
> e.g. see
> http://git.debian.org/?p=pkg-exppsy/statsmodels.git;a=blob;f=debian/rules;h=0b534f7258bf5c2cf3d5e10bcc8de5376516d114;hb=refs/heads/debian
> having
>
> 27 override_dh_auto_install: ${PYVERS:%=python-install%}
> 28 dh_auto_install
> 29 find debian -wholename \*scikits/__init__.py -delete
--
Thanks for your help and kind regards.
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/il3fba$lqk$1...@dough.gmane.org
Re: GPL applications using Python (OpenSSL issue?)
On Mon, Mar 7, 2011 at 7:48 PM, Ulrik Sverdrup wrote: > Can GPLv3+ applications written in Python exist in Debian main? The > applications in question do not use an openssl exception. > > Python uses OpenSSL so the moment the application starts, it is linking > against it too: > > $ objdump -p /usr/bin/python2.6 | grep NEEDED > NEEDED libpthread.so.0 > NEEDED libdl.so.2 > NEEDED libutil.so.1 > NEEDED libssl.so.0.9.8 > NEEDED libcrypto.so.0.9.8 > NEEDED libz.so.1 > NEEDED libm.so.6 > NEEDED libc.so.6 > > In my case I am talking about a GPLv3+ package that exists in Debian -- > kupfer > > Where do I draw the line for using/linking against ssl? > > a) Using Python2.6 > b) Unintentionally introducing _ssl or ssl into the imported modules > (import any of urllib, httplib, socket etc!) > c) Unintentionally using ssl (use urllib.urlopen on URL provided by > user -- if it's https we are using openssl) > d) Intentionally using ssl (import ssl and use httplib.HTTPSConnection > and verify certificates) e) use something like http://fedoraproject.org/wiki/FedoraCryptoConsolidation and port python to http://fedoraproject.org/wiki/Nss_compat_ossl Bastien -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTikNs1j0DyR9KD0ra4dZ0wU2b=wsl0ctdcyqf...@mail.gmail.com
