Thread: [Pythonsiphon-devel] features
Status: Beta
Brought to you by:
ssthapa
Menu
▾
▴
pythonsiphon-devel
|
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...
------------------------------------------------------------------
|
|
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-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 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: 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: 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...
------------------------------------------------------------------
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X