pythonsiphon-devel Mailing List for Ciphon
Status: Beta
Brought to you by:
ssthapa
Menu
▾
▴
pythonsiphon-devel — mailing list for developers of siphon
You can subscribe to this list here.
| 2002 |
Jan
(9) |
Feb
(6) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
(1) |
Dec
|
|---|
|
From: Suchandra T. <s-t...@al...> - 2002-11-25 21:02:21
|
I've released a new version of ciphon that adds among other things: * support for ftp and http servers * automatic bug reports (the email server can be specified so windows users can use this also) * pdb postmortem (setting the debug config option switches between this and the emailed bug report) * exception handling has been tightened up a bit to make debugging a little easier * a working windows installation The code is available as a source download from sourceforge (http://sourceforge.net/projects/pythonsiphon/) or using by anonymous cvs from sourceforge. As always I'm open to suggestions on what features ciphon should incorporate. -- ------------------------------------------------------------------ Suchandra S. Thapa s-t...@al... ------------------------------------------------------------------ |
|
From: Suchandra T. <s-t...@al...> - 2002-09-24 23:51:07
|
I've uploaded my cvs repository to the sourceforge.net page. There are two additions to the cvs version of the code that are not present in the 0.35 release: a function to catch errors and email a bug report to the pythonsiphon-bugs mailing list and module to open tar.gz files so the tar program does not need to be present. You can grab the cvs code using: cvs -d:pserver:ano...@cv...:/cvsroot/pythonsiphon login cvs -z3 -d:pserver:ano...@cv...:/cvsroot/pythonsiphon co ciphon Gerhard, could you resubmit or forward the patch you had for the project so that I can integrate it into the current code? -- ------------------------------------------------------------------ Suchandra S. Thapa s-t...@al... ------------------------------------------------------------------ |
|
From: Suchandra T. <s-t...@al...> - 2002-09-09 23:54:31
|
On Sun, 2002-09-08 at 20:36, Gerhard H=E4ring wrote:
Now, is there anything going on in this project or has it died, yet?
I haven't had much time to do work on it but I've done some work in
regards to automatically sending bugreports to a mailing list and on
integrating a tar file module into the program so that the tar program
doesn't need to be used. I'll try to get my cvs copy uploaded to the
sourceforge project page by the end of the week.
--=20
------------------------------------------------------------------
Suchandra S. Thapa=20
s-t...@al...
------------------------------------------------------------------
|
|
From: Gerhard <ger...@gm...> - 2002-09-09 01:36:44
|
Now, is there anything going on in this project or has it died, yet? -- Gerhard |
|
From: Gerhard <ger...@gm...> - 2002-02-18 05:52:45
|
Le 15/02/02 ? 17:11, Thomas Heller écrivit: > From: "Suchandra Thapa" <s-t...@al...> > > On Fri, Feb 15, 2002 at 11:38:01AM +0100, Thomas Heller wrote: > > > Sounds great! > > > Are you going to use the CVS repository on SF again, or do you only > > > use SF to release the distribution? > > > > I primarily use SF for releases and keep the code on a CVS repository > > on my local machine. > > Don't you think ciphon would improve faster with collaborative development? > > > I did have a question for you regarding windows. Currently ciphon > > keeps its' settings in the user's home directory on windows is there > > any particular location to place this information or could I just use > > something like Program Files/Ciphon/? > Well, as numerous threads on c.l.p show, there is no real 'home > directory' on windows. Why don't you install ciphon with distutils, > where the top-level script would go into the python Scripts directory, > and you could also store the configuration there. The problem with > 'Program Files'\Ciphon is that this directory also depends on the > windows version/language/maybe other stuff. To be sure, this > directory has to be retrieved from the registry or with a win32 API > call. For example, in german versions of windows this directory is > named 'Programme'. A simple solution would be to make the directory overridable by an environment variable, like CIPHON_HOME, if it exists, use it, else use HOME, else fail. Gerhard -- This sig powered by Python! Außentemperatur in München: 1.9 °C Wind: 1.9 m/s |
|
From: Suchandra T. <s-t...@al...> - 2002-02-15 23:48:36
|
On Fri, Feb 15, 2002 at 05:11:53PM +0100, Thomas Heller wrote:
> > I primarily use SF for releases and keep the code on a CVS repository
> > on my local machine.
>
> Don't you think ciphon would improve faster with collaborative development?
Sourceforge allows uploads of patches regardless of whether the cvs
is currently there or not. My concern with sourceforge is primarily
over how readily accessible the cvs tree would be if I wanted to get the
entire tree. Also I have some concerns over whether sourceforge will
be around in the long term. However, I'll look into putting my cvs
code on sourceforge after the next release.
> Well, as numerous threads on c.l.p show, there is no real 'home directory'
> on windows. Why don't you install ciphon with distutils, where the
> top-level script would go into the python Scripts directory, and you
> could also store the configuration there.
Okay, is there a way to determine that? Some distutils function or
something similar?
--
------------------------------------------------------------------
Suchandra S. Thapa
s-t...@al...
------------------------------------------------------------------
|
|
From: Thomas H. <tho...@io...> - 2002-02-15 16:12:19
|
From: "Suchandra Thapa" <s-t...@al...> > On Fri, Feb 15, 2002 at 11:38:01AM +0100, Thomas Heller wrote: > > Sounds great! > > Are you going to use the CVS repository on SF again, or do you only > > use SF to release the distribution? > > I primarily use SF for releases and keep the code on a CVS repository > on my local machine. Don't you think ciphon would improve faster with collaborative development? > I did have a question for you regarding windows. Currently ciphon > keeps its' settings in the user's home directory on windows is there > any particular location to place this information or could I just use > something like Program Files/Ciphon/? Well, as numerous threads on c.l.p show, there is no real 'home directory' on windows. Why don't you install ciphon with distutils, where the top-level script would go into the python Scripts directory, and you could also store the configuration there. The problem with 'Program Files'\Ciphon is that this directory also depends on the windows version/language/maybe other stuff. To be sure, this directory has to be retrieved from the registry or with a win32 API call. For example, in german versions of windows this directory is named 'Programme'. Thomas |
|
From: Suchandra T. <s-t...@al...> - 2002-02-15 16:01:33
|
On Fri, Feb 15, 2002 at 11:38:01AM +0100, Thomas Heller wrote:
> Sounds great!
> Are you going to use the CVS repository on SF again, or do you only
> use SF to release the distribution?
I primarily use SF for releases and keep the code on a CVS repository
on my local machine.
I did have a question for you regarding windows. Currently ciphon
keeps its' settings in the user's home directory on windows is there
any particular location to place this information or could I just use
something like Program Files/Ciphon/?
--
------------------------------------------------------------------
Suchandra S. Thapa
s-t...@al...
------------------------------------------------------------------
|
|
From: Thomas H. <tho...@io...> - 2002-02-15 10:38:22
|
> I've been a little too busy to get much work on ciphon done, but I > have a little more time and will hopefully be completing a new relase by > early next week. I'm adding native tar file reading, windows support, > better error/status messages, some initial support for binary packages, > and an integrated bug report facility. Most of these are already completed, > I just need to finish some loose ends and test them to make sure everything > is working properly. Sounds great! Are you going to use the CVS repository on SF again, or do you only use SF to release the distribution? Thomas |
|
From: Suchandra T. <s-t...@al...> - 2002-02-14 23:25:06
|
I've been a little too busy to get much work on ciphon done, but I have a little more time and will hopefully be completing a new relase by early next week. I'm adding native tar file reading, windows support, better error/status messages, some initial support for binary packages, and an integrated bug report facility. Most of these are already completed, I just need to finish some loose ends and test them to make sure everything is working properly. -- ------------------------------------------------------------------ Suchandra S. Thapa s-t...@al... ------------------------------------------------------------------ |
|
From: Suchandra T. <s-t...@al...> - 2002-01-06 22:53:35
|
On Sat, Jan 05, 2002 at 05:25:14AM +0100, Gerhard Häring wrote:
> I've recently converted to Debian from SuSE (RPM based), so I could
> perhaps help with or at least test the dpkg stuff. I've also created
> several RPM packages and I'm maintaining one FreeBSD "port". I think I
> know RPM reasonably well.
The problem with debian installs is that distutils doesn't have any
support for creating a deb package. I would need to write that, but
really don't consider it a priority at the moment.
> I think binary packages are much more important, because that's the only
> reasonable choice for most Python users on some platforms like Windows
> (the chances somebody has installed Cygwin or mingw32 or even Visual C++
> are pretty slim on win32).
I think I'm beginning to agree with your assesment. Although I would
really prefer that the rpm installs work, the fact that it requires packages
have a MANIFEST or MANIFEST.in file otherwise the build will fail makes me
believe that it may be more productive to focus on other issues right now.
> Is the project currently about the ultimate Python package management
> system or more a proof-of-conept? That's IMO an important point. I'm
> personally looking at it more as a proof-of-concept. But these are very
> important, too.
I initially started this out as a proof of concept program in the
hopes that design issues could be discussed and tested. However, ciphon
seems to be heading towards being an actual package management system for
production use.
> So IMHO we shouldn't try to cram all the features in: native package
> management is not so imporant IMHO, binary packages are, so are
> different methods of unpacking like .tar.gz and .zip.
Cross platform support is an important area. Although I'm not entirely
sure about the best way, I'll probably put some sort of support for it in
and see how well it works.
> Other useful features would be uninstalling and upgrading packages and
> their dependencies, but once package dependencies are recorded, this
> would probably be trivial.
Upgrading should be okay, uninstalling would be more difficult since
distutils doesn't record the installed files for packages. That's one of
the reasons why I wanted native support. However, the perl CPAN shell
doesn't seem to support uninstallation either.
--
------------------------------------------------------------------
Suchandra S. Thapa
s-t...@al...
------------------------------------------------------------------
|
|
From: Suchandra T. <s-t...@al...> - 2002-01-06 22:28:50
|
On Fri, Jan 04, 2002 at 09:22:23PM +0100, Thomas Heller wrote:
> Bugs I did find:
>=20
> ciphon can only install one package. To installl another package,
> you must quit and restart, because Configuration.getServerAddress()
> runs out of servers (each entry in the list is used once, and then
> deleted).
That should be relatively easy to fix. =20
> I had to always use ciphon's ftplib2 instead of Python 2.2's
> ftplib module (this has also been reported to c.l.p).
I've tried the python2.2 ftplib on RH7.2 and it works. Perhaps
there is a problem with the windows version.
> Patches are attached, also Jason Petrone's tarfile.py.
Do you know what's the license on the tarfile? His web page didn't
mention anything. =20
> One additional suggestion:
> ciphon is very quiet. An option to print *some* output
> for long lasting actions (downloading) would be nice.
> Also the error output could be improved...
Yes, I think error reporting and documentation are some of the biggest=
=20
deficiencies in ciphon right now.
--=20
------------------------------------------------------------------
Suchandra S. Thapa=20
s-t...@al...
------------------------------------------------------------------
|
|
From: Gerhard <ger...@gm...> - 2002-01-05 04:25:22
|
Le 03/01/02 à 16:23, Suchandra Thapa écrivit: > Hi, I would like to know what suggestions people on this list > have for features to add to ciphon. At this point I have some > confidence in ciphon's ability to download and install modules on > unix platforms using the standard install. I'm not quite so confident > about rpm installs. I've received a patch from Gerhard Häring that > uses a temporary directory for downloading and building which I plan > on incorporating. I also think Thomas Heller has gotten ciphon 0.3.4 > working on windows. > Currently my todo list for ciphon is (in no particular order): > > some form of windows support > better rpm support > support for binary packages > support for debian pkgs (not for a while unfortunately) I've recently converted to Debian from SuSE (RPM based), so I could perhaps help with or at least test the dpkg stuff. I've also created several RPM packages and I'm maintaining one FreeBSD "port". I think I know RPM reasonably well. I don't view native installation (RPM/dkpkg/win32/FreeBSD package, whatver) as a priority. At least on Unixen, it's IMHO of questionable value. Pythonsiphon must eventually know about package dependencies in its own database, anyway. I think binary packages are much more important, because that's the only reasonable choice for most Python users on some platforms like Windows (the chances somebody has installed Cygwin or mingw32 or even Visual C++ are pretty slim on win32). Is the project currently about the ultimate Python package management system or more a proof-of-conept? That's IMO an important point. I'm personally looking at it more as a proof-of-concept. But these are very important, too. So IMHO we shouldn't try to cram all the features in: native package management is not so imporant IMHO, binary packages are, so are different methods of unpacking like .tar.gz and .zip. Other useful features would be uninstalling and upgrading packages and their dependencies, but once package dependencies are recorded, this would probably be trivial. Gerhard -- mail: gerhard <at> bigfoot <dot> de registered Linux user #64239 web: http://www.cs.fhm.edu/~ifw00065/ OpenPGP public key id 86AB43C0 public key fingerprint: DEC1 1D02 5743 1159 CD20 A4B6 7B22 6575 86AB 43C0 reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b'))) |
|
From: Thomas H. <tho...@io...> - 2002-01-04 20:23:15
|
Bugs I did find: ciphon can only install one package. To installl another package, you must quit and restart, because Configuration.getServerAddress() runs out of servers (each entry in the list is used once, and then deleted). I had to always use ciphon's ftplib2 instead of Python 2.2's ftplib module (this has also been reported to c.l.p). Patches are attached, also Jason Petrone's tarfile.py. One additional suggestion: ciphon is very quiet. An option to print *some* output for long lasting actions (downloading) would be nice. Also the error output could be improved... Enjoy, Thomas |
|
From: Suchandra T. <s-t...@al...> - 2002-01-04 20:12:54
|
On Fri, Jan 04, 2002 at 08:19:02PM +0100, Thomas Heller wrote:
>=20
> Yes, pure python. Here's the changed code (Install.__unpack):
>=20
> def __unpack(self):
> """Unpack a package so that it can be built and installed"""
> from tarfile import TarFile
> tf =3D TarFile(self.__fileName)
> tf.untar('.')
> return
>=20
> >=20
> > > 3. How does ciphon use rpm's under linux? If I understand correctly,
> > > you download the .tar.gz package, build an rpm from it, and then
> > > install it? Maybe I should do something similar under windows (buildi=
ng
> > > and then starting a bdist_wininst installer).
> >=20
> > Yes, if the user specifies a rpm installation then ciphon builds
> > using bdist_rpm and then installs the generated rpm.
> Knowing nearly nothing about rpm, what do you gain by this? Uninstallation
> support?
rpm maintains a database of the installed software, the files installed=
by
each package, and some metainfo on the files. Besides uninstall support, r=
pm
allows you to verify the integrity of the files since it tracks the=20
owner, group, permissions, and a md5 hash of the files. rpm also provides=
=20
for depedency checking and for running pre or post install and uninstall=20
scripts. =20
> Could installtype simply be 'source' or 'setup' to install by setup.py,
> and 'native' or 'system' to use bdist_wininst, rpm, or whatever
> is the preferred method for the system?
However, this would require another option to specify the native=20
installer since distutils can't determine whether a linux system is using
rpm or not. I'm leaning towards adding another option to specify whether
the installs are to be made using binary packages or not. This in conjunct=
ion
with the install type should cover the cases. =20
> BTW: How is uninstallation handled? The bdist_wininst installer includes =
an
> uninstaller, but this one of course does not remove the packes from
> ~/.ciphon/installed.xml...
Currently it's not an option. Distutils doesn't record the location of
installed files so there isn't a way to uninstall packages. It's possible
with windows or rpm or debian based systems however. =20
--=20
------------------------------------------------------------------
Suchandra S. Thapa=20
s-t...@al...
------------------------------------------------------------------
|
|
From: Thomas H. <tho...@io...> - 2002-01-04 19:20:06
|
From: "Suchandra Thapa" <s-t...@al...> > > > 2. Windows support: I simply replaced most open(fname, "w") calls > > with open(fname, "wb"). Windows always needs the 'b' flag for > > binary files. Since I could not find a suitable tar.exe running on > > windows, I took the first tarfile Python module I could find > > (from Jason Pedrone, http://www.demonseed.net/~jp/code/tarfile.py) > > and used it from ciphon. > > I can add code to ciphon to choose the mode based on the the platform > distutils is running on. I'll look into adding the tar file support into > ciphon. Is the module you mentioned a pure python module? Yes, pure python. Here's the changed code (Install.__unpack): def __unpack(self): """Unpack a package so that it can be built and installed""" from tarfile import TarFile tf = TarFile(self.__fileName) tf.untar('.') return > > > 3. How does ciphon use rpm's under linux? If I understand correctly, > > you download the .tar.gz package, build an rpm from it, and then > > install it? Maybe I should do something similar under windows (building > > and then starting a bdist_wininst installer). > > Yes, if the user specifies a rpm installation then ciphon builds > using bdist_rpm and then installs the generated rpm. Knowing nearly nothing about rpm, what do you gain by this? Uninstallation support? > Doing something > similar for windows involves changing the configuration handling to support > a windows option for installtype and then adding a check in the Installer > class. The changes should take about 10-20 lines of code. Could installtype simply be 'source' or 'setup' to install by setup.py, and 'native' or 'system' to use bdist_wininst, rpm, or whatever is the preferred method for the system? BTW: How is uninstallation handled? The bdist_wininst installer includes an uninstaller, but this one of course does not remove the packes from ~/.ciphon/installed.xml... > > PS: I have some problems reading your mails, Suchandra, because I always > > see them as empty messages with attachments. I'm sure it's my fault because > > I'm using outlook express... Someone has a tip for me? > > Probably due too the gpg signatures on my emails. I'll disable them > on the list and in messages to you. Great! It did work in this case. Thomas |
|
From: Suchandra T. <s-t...@al...> - 2002-01-04 17:09:59
|
On Fri, Jan 04, 2002 at 10:31:02AM +0100, Thomas Heller wrote:
> 1. I would mostly like some code/explanation/whatever about how
> to submit a package to ciphon. I assume currently you submit
> packages manually?
I'll add more document this within the package. Currently
the submission is done manually. There are two utilities that are
used to generate the repository. The createspec.py script (in /utils) asks
the user a few questions and then creates a file with the specification
for the package. The second utility createlist.py takes a directory
with package specifications and package tar balls and then creates
a packages.xml and a directory for distribution. The packages.xml is a
compilation of the individual package specifications with package size and
the package's location relative to the base of the distribution directory.
The distribution directory created by the createlist.py contains 16
subdirectories (0-9, A-F) where packages can be located. The packages
are placed in the subdirectory that matches the first character of the SHA
hash of the package's name.
Right now I have a group of packages and specifications and just run
the createlist.py whenever I update a package and upload the directory and
packages.xml file to the tummy server.
The other file used is the servers.xml but I will manually change this.
> 2. Windows support: I simply replaced most open(fname, "w") calls
> with open(fname, "wb"). Windows always needs the 'b' flag for
> binary files. Since I could not find a suitable tar.exe running on
> windows, I took the first tarfile Python module I could find
> (from Jason Pedrone, http://www.demonseed.net/~jp/code/tarfile.py)
> and used it from ciphon.
I can add code to ciphon to choose the mode based on the the platform
distutils is running on. I'll look into adding the tar file support into
ciphon. Is the module you mentioned a pure python module?
> 3. How does ciphon use rpm's under linux? If I understand correctly,
> you download the .tar.gz package, build an rpm from it, and then
> install it? Maybe I should do something similar under windows (building
> and then starting a bdist_wininst installer).
Yes, if the user specifies a rpm installation then ciphon builds
using bdist_rpm and then installs the generated rpm. Doing something
similar for windows involves changing the configuration handling to support
a windows option for installtype and then adding a check in the Installer
class. The changes should take about 10-20 lines of code.
> 4. Support for binary packages is essential under Windows, because
> a lot of people have no compiler. Additional catch: Extension modules
> to run under windows must be compiled separately for each Python version!
That is a bit of a problem, however it shouldn't be to difficult to
handle. I think there will probably be similar problems with extension
modules under unix platforms. I'm still trying to figure out a way to
cleanly handle the possible permutations of libraries , platforms, and python
versions.
> PS: I have some problems reading your mails, Suchandra, because I always
> see them as empty messages with attachments. I'm sure it's my fault because
> I'm using outlook express... Someone has a tip for me?
Probably due too the gpg signatures on my emails. I'll disable them
on the list and in messages to you.
--
------------------------------------------------------------------
Suchandra S. Thapa
s-t...@al...
------------------------------------------------------------------
|
|
From: Thomas H. <tho...@io...> - 2002-01-04 09:32:09
|
> Hi, I would like to know what suggestions people on this list > have for features to add to ciphon. At this point I have some > confidence in ciphon's ability to download and install modules on > unix platforms using the standard install. I'm not quite so confident > about rpm installs. I've received a patch from Gerhard H=E4ring that > uses a temporary directory for downloading and building which I plan > on incorporating. I also think Thomas Heller has gotten ciphon 0.3.4 > working on windows. > Currently my todo list for ciphon is (in no particular order): > > some form of windows support > better rpm support > support for binary packages > support for debian pkgs (not for a while unfortunately) > Suchandra, 1. I would mostly like some code/explanation/whatever about how to submit a package to ciphon. I assume currently you submit packages manually? 2. Windows support: I simply replaced most open(fname, "w") calls with open(fname, "wb"). Windows always needs the 'b' flag for binary files. Since I could not find a suitable tar.exe running on windows, I took the first tarfile Python module I could find (from Jason Pedrone, http://www.demonseed.net/~jp/code/tarfile.py) and used it from ciphon. 3. How does ciphon use rpm's under linux? If I understand correctly, you download the .tar.gz package, build an rpm from it, and then install it? Maybe I should do something similar under windows (building and then starting a bdist_wininst installer). 4. Support for binary packages is essential under Windows, because a lot of people have no compiler. Additional catch: Extension modules to run under windows must be compiled separately for each Python version! Regards, Thomas PS: I have some problems reading your mails, Suchandra, because I always see them as empty messages with attachments. I'm sure it's my fault becau= se I'm using outlook express... Someone has a tip for me? |
|
From: Suchandra T. <s-t...@al...> - 2002-01-03 22:05:20
|
Hi, I would like to know what suggestions people on this list=20
have for features to add to ciphon. At this point I have some=20
confidence in ciphon's ability to download and install modules on
unix platforms using the standard install. I'm not quite so confident
about rpm installs. I've received a patch from Gerhard H=E4ring that
uses a temporary directory for downloading and building which I plan
on incorporating. I also think Thomas Heller has gotten ciphon 0.3.4=20
working on windows.
Currently my todo list for ciphon is (in no particular order):
some form of windows support
better rpm support
support for binary packages
support for debian pkgs (not for a while unfortunately)
--=20
------------------------------------------------------------------
Suchandra S. Thapa=20
s-t...@al...
------------------------------------------------------------------
|
