Hi all --
at long last, I have fixed two problems that a couple people noticed a
while ago:
* I folded in Amos Latteier's NT patches almost verbatim -- just
changed an `os.path.sep == "/"' to `os.name == "posix"' and added
some comments bitching about the inadequacy of the current library
installation model (I think this is Python's fault, but for now
Distutils is slavishly aping the situation in Python 1.5.x)
* I fixed the problem whereby running "setup.py install" without
doing anything else caused a crash (because 'build' hadn't yet
been run). Now, the 'install' command automatically runs 'build'
before doing anything; to make this bearable, I added a 'have_run'
dictionary to the Distribution class to keep track of which commands
have been run. So now not only are command classes singletons,
but their 'run' method can only be invoked once -- both restrictions
enforced by Distribution.
The code is checked into CVS, or you can download a snapshot at
http://www.python.org/sigs/distutils-sig/distutils-19990607.tar.gz
Hope someone (Amos?) can try the new version under NT. Any takers for
Mac OS?
BTW, all parties involved in the Great "Where Do We Install Stuff?"
Debate should take a good, hard look at the 'set_final_options()' method
of the Install class in distutils/install.py; this is where all the
policy decisions about where to install files are made. Currently it
apes the Python 1.5 situation as closely as I could figure it out.
Obviously, this is subject to change -- I just don't know to *what* it
will change!
Greg
--
Greg Ward - software developer gward(a)cnri.reston.va.us
Corporation for National Research Initiatives
1895 Preston White Drive voice: +1-703-620-8990
Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913
Hi all,
I've been aware that the distutils sig has been simmerring away, but
until recently it has not been directly relevant to what I do.
I like the look of the proposed api, but have one question. Will this
support an installed system that has multiple versions of the same
package installed simultaneously? If not, then this would seem to be a
significant limitation, especially when dependencies between packages
are considered.
Assuming it does, then how will this be achieved? I am presently
managing this with a messy arrangement of symlinks. A package is
installed with its version number in it's name, and a separate
directory is created for an application with links from the
unversioned package name to the versioned one. Then I just set the
pythonpath to this directory.
A sample of what the directory looks like is shown below.
I'm sure there is a better solution that this, and I'm not sure that
this would work under windows anyway (does windows have symlinks?).
So, has this SIG considered such versioning issues yet?
Cheers,
Tim
--------------------------------------------------------------
Tim Docker timd(a)macquarie.com.au
Quantative Applications Division
Macquarie Bank
--------------------------------------------------------------
qad16:qad $ ls -l lib/python/
total 110
drwxr-xr-x 2 mts mts 512 Nov 11 11:23 1.1
-r--r----- 1 root mts 45172 Sep 1 1998 cdrmodule_0_7_1.so
drwxr-xr-x 2 mts mts 512 Sep 1 1998 chart_1_1
drwxr-xr-x 3 mts mts 512 Sep 1 1998 Fnorb_0_7_1
dr-xr-x--- 3 mts mts 512 Nov 11 11:21 Fnorb_0_8
drwxr-xr-x 3 mts mts 1536 Mar 3 12:45 mts_1_1
dr-xr-x--- 7 mts mts 512 Nov 11 11:22 OpenGL_1_5_1
dr-xr-x--- 2 mts mts 1024 Nov 11 11:23 PIL_0_3
drwxr-xr-x 3 mts mts 512 Sep 1 1998 Pmw_0_7
dr-xr-x--- 2 mts mts 512 Nov 11 11:21 v3d_1_1
qad16:qad $ ls -l lib/python/1.1
total 30
lrwxrwxrwx 1 root other 29 Apr 10 10:43 _glumodule.so -> ../OpenGL_1_5_1/_glumodule.so
lrwxrwxrwx 1 root other 30 Apr 10 10:43 _glutmodule.so -> ../OpenGL_1_5_1/_glutmodule.so
lrwxrwxrwx 1 root other 22 Apr 10 10:43 _imaging.so -> ../PIL_0_3/_imaging.so
lrwxrwxrwx 1 root other 36 Apr 10 10:43 _opengl_nummodule.so -> ../OpenGL_1_5_1/_opengl_nummodule.so
lrwxrwxrwx 1 root other 27 Apr 10 10:43 _tkinter.so -> ../OpenGL_1_5_1/_tkinter.so
lrwxrwxrwx 1 mts mts 21 Apr 10 10:43 cdrmodule.so -> ../cdrmodule_0_7_1.so
lrwxrwxrwx 1 mts mts 12 Apr 10 10:43 chart -> ../chart_1_1
lrwxrwxrwx 1 root other 12 Apr 10 10:43 Fnorb -> ../Fnorb_0_8
lrwxrwxrwx 1 mts mts 12 Apr 10 10:43 mts -> ../mts_1_1
lrwxrwxrwx 1 root other 15 Apr 10 10:43 OpenGL -> ../OpenGL_1_5_1
lrwxrwxrwx 1 root other 33 Apr 10 10:43 opengltrmodule.so -> ../OpenGL_1_5_1/opengltrmodule.so
lrwxrwxrwx 1 root other 33 Apr 10 10:43 openglutil_num.so -> ../OpenGL_1_5_1/openglutil_num.so
lrwxrwxrwx 1 root other 10 Apr 10 10:43 PIL -> ../PIL_0_3
lrwxrwxrwx 1 mts mts 10 Apr 10 10:43 Pmw -> ../Pmw_0_7
lrwxrwxrwx 1 root other 10 Apr 10 10:43 v3d -> ../v3d_1_1
Hello Everybody:
I am trying to install distribute-0.6.25 in a windows 7 machine. I have
python 2.7.3 in 32 bits, although the machine is 64 bits. I installed
the 32 bit python version because I want to install ipython and there
is no 64 bit builds of the Windows installer for ipython.
In any case, upon installing disuitils with
python setup.py install
I get the following error
error:
C:\manuel\prog_red\python\distribute-0.6.25\distribute-0.6.25\setuptools\cli-32.exe:
No such file or directory
Any help will be greatly appeciated. Thanks,
Manuel
--
Manuel López Mariscal
Depto. de Oceanografía Física/CICESE
malope(a)cicese.mx
Hi all,
I recently came upon Tarek's blogpost [1] about converting Python packages to rpm specfiles. I have pretty good knowledge of this, as I am a Fedora package maintainer and Python is one of my main responsibilities. I have always wanted to become a Python developer and becoming part of distutils-sig and trying to give a helping hand with RPM related stuff is probably a good entry point for me :)
To introduce myself, I work at Red Hat as a package maintainer for dynamic languages, I am author of the new Fedora-used pyp2rpm [2], [3], which tries to do exactly what Py2RPM is supposed to be. (Well, it's not perfect, but it can do 90 % of the work, usually. So far, it doesn't work with distutils2, but I'll probably be working on that when Python 3.3 gets released.) I also have some minor not-yet-released projects in Python, I work with Django and I'm just a Python enthusiast. In Fedora, I am a maintainer/comaintainer of both Python and Python3, Django and another 15+ (and growing) set of packages.
Thanks for reading this through :) I'm looking forward to working with - and learning from - all of you.
--
Regards,
Bohuslav "Slavek" Kabrda.
[1] http://ziade.org/2011/03/25/bdist_rpm-is-dead-long-life-to-py2rpm/
[2] http://pypi.python.org/pypi/pyp2rpm
[3] https://bitbucket.org/bkabrda/pyp2rpm
Hi,
I am looking for a convention (i.e. kind of PEP) about package names:
"how to choose a good package name".
I couldn't find a PEP which gives guidelines about it.
PEP 8 gives some guidelines about "syntax" of package names.
I found articles like "Rules of thumb" section of
http://www.martinaspeli.net/articles/the-naming-of-things-package-names-and….
But I was looking for something more "official".
And thus, I was thinking of a PEP, or something similar.
Scope:
* we have tools to create and distribute packages. Not covered by this
thread.
* we have tools to create namespace packages. Not covered by this thread.
* we have conventions about "syntax" of module names in PEP 8. Not
covered by this thread.
* do we have conventions, or at least guidelines, to choose a name for a
package?
I'm not to write this guide here (I'm not an expert about it), but, if
such a PEP or documentation doesn't exist, here are some considerations
to start:
* The Zen of Python tells "There should be one-- and preferably only one
--obvious way to do it."
*
http://www.martinaspeli.net/articles/the-naming-of-things-package-names-and…
seems interesting
* maybe
http://guide.python-distribute.org/specification.html#naming-specification
is a cool place
* maybe http://docs.python.org/dev/packaging/ is the right place for
that kind of information
* We should cover both simple packages and namespace packages.
* I guess some teams or communities already have such conventions. As an
example, does the Plone community have one?
* I feel there are too much de facto standards on Pypi: as an example
Plone community uses namespaces like "plone.app.theming", whereas Django
community uses "django-*" pattern, there are also many "pyramid_*"
packages...
* We should cover public packages published on Pypi, but also public
packages published on online repositories like Github, and also private
(personal or corporate) packages.
* I know we cannot migrate existing package names.
* We could recommend something for new packages.
Here are quotes seen in a recent thread about PEP 420
(http://mail.python.org/pipermail/import-sig/2012-May/000631.html),
which make me believe a convention would be useful.
Notice that, in fact, I discovered PEP 420 while searching for a PEP
about "how to choose a good namespace".
Le 13/05/2012 19:25, PJ Eby a écrit :
> Regarding the nesting issue and persuading Django developers to use
> namespaces, I would note that there isn't any reason for namespaces to
> be deeply nested in the first place. By convention, top-level
> namespace packages should be the name of a project or its sponsoring
> organization, which means there is rarely a need for deep nesting.
> Even cases like zope.app and peak.util are rare: usually a project or
> organization will have only one such "miscellaneous" namespace with
> lots of separately-distibuted components.
>
> (After all, the main reason to *have* a namespace package is to have
> separately-distributed subpackages. So, self-contained packages don't
> need to have namespaces of their own, almost by definition.)
>
> Anyway, what I've noticed is that when people want to deeply nest
> namespaces, it's usually because they're trying to share a namespace
> across organizations, like making a shared 'net.*' namespace. The
> idea of namespaces isn't for that kind of categorization, though, it's
> for *ownership*. If two developers are fighting over where to put
> something in a category hierarchy, it's a sign that they need to be
> working in different namespaces, with each developer staking a claim
> to a *top-level* package -- like OSAF's osaf.*, Zope Corporation's
> zc.* (vs. the community project's zope.*), and so on.
>
> When developers use namespaces for project/ownership distinction, the
> resulting package hierarchies can be pretty much as flat as you like.
If I had to explain it to another Python developer, I wish I could give
him an hyperlink and say "read and follow the convention".
Le 13/05/2012 20:56, "Martin v. Löwis" a écrit :
> In Java, people apparently want that because they get these deeply
> nested directory hiearchies (org/apache/commons/betwixt/expression).
> It's apparently possible to condense this into
> org.apache.commons.betwixt/expression (which isn't a shorter string,
> but fewer cd commands / explorer clicks / .svn folders).
>
> I predict that people will start using PEP 420 in the reversed-domain
> fashion also, so we eventually might end up wanting something like
> this for Python.
Could we anticipate namespace usage? At least for some "simple" things
that already are de facto standards.
As an example, I guess we could state about "reasonable maximum
namespace depth", because on Pypi there is not many packages with more
than 3 levels.
Regards,
Benoit
If you don't use zc.buildoutsftp on Windows, please ignore :)
Does anyone use zc.buildoutsftp on windows?
There is some windows support that I added several years ago,
presumably because someone sent me a patch. I don't use
zc.buildoutsftp on Windows myself.
When I wrote, zc.buildoutsftp, it had no automated tests, because I
couldn't figure out a sane way to write automated tests for it.
Recently, I've written mock-based tests, but these tests are
unix-ish-specific. I know they'll fail on Windows. I can't say I
really care. :) I'd rather have half-way decent tests that fail on
windows than no tests anywhere.
I've endeavored to write the code in a platform-independent manner,
but without tests, it's easy to screw up.
If anyone is using windows, and is willing to help at least make sure
the new revision works on windows or is willing to help factor the
tests to run on Windows, then I'm happy to work with them.
Jim
--
Jim Fulton
http://www.linkedin.com/in/jimfulton
Jerky is better than bacon! http://zo.pe/Kqm
