Mailman 3 January 2013 - Distutils-SIG

ImportError running 'test' on namespace package - other package in namespace not found
by Jason R. Coombs April 17, 2020

April 17, 2020

I've got two projects: mynamespace.myprojectA and mynamespace.myprojectB myprojectB depends on myprojectA. I'm using setuptools 0.6c8 to manage both projects. Both projects are registered using 'setup develop'. Both projects are accessible from an interactive interpreter: PS C:\Users\me\projects> python Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import mynamespace.myprojectA >>> import mynamespace.myprojectB >>> from mynamespace.myprojectA import mymoduleZ However, when I run 'setup test' in myprojectB, the tests fail with File ".mymoduleZ.py", line NNN, in [some context] from mynamespace.myprojectA.mymoduleZ import MyClassC ImportError: No module named myprojectA.mymoduleZ In setup.py, the test_suite is nose.collector. I searched and couldn't find anyone else with this problem. Is this a supported configuration? Is there something I can do to make tests work with interdependent projects with the same root namespace? If there's not something obvious I should be doing differently, I'm happy to put together a minimal test case that reproduces the problem. Any suggestions are appreciated. Sincerely, Jason R. Coombs

3 6

Upgrading dependencies
by Charlie Moad April 29, 2018

April 29, 2018

Is it currently possible to upgrade dependencies as well when upgrading a packages? If not, this would be a really nice feature to add to easy_install. Maybe a call like: easy_install --upgrade --upgrade-deps Package Obviously it makes sense to leave this off by default. Thanks, Charlie

2 1

Changes to --find-links and --upgrade in SVN
by Phillip J. Eby April 29, 2018

April 29, 2018

Elvelind Grandin reported a problem with the "develop" command that turned out to be a flaw in its --find-links support. Specifically, it wasn't ever processing the links. :) In the process of fixing it, I wound up cleaning up an annoying (to me, at least) quirk of the previous workings of --find-links. It used to be that find-links would always be processed first, no matter what, even if you were doing a completely local operation. This would've been especially annoying if it carried over into "develop", so I made some changes. Now, if an item passed to --find-links is local (a filename or file: URL), or a direct link to an egg or other distribution, it is indexed immediately. Remote URLs are now only retrieved if a dependency can't be resolved locally, or if you use the -U or --upgrade options (this goes for "develop" too). Note that this is a behavior change for easy_install, which was effectively treating --find-links as though you'd specified --upgrade in certain cases. So, if you're used to getting upgrades downloaded as a result of using --find-links, please note that this will no longer happen. EasyInstall will now *only* go online if a dependency can't be resolved locally, if -U or --upgrade is used, or if you provided suitable direct URLs via an argument or --find-links, or via a link in a local .html file.

2 1

Problems with svn in windows
by Sharky On PTNet April 29, 2018

April 29, 2018

Hi, I´m trying to do "easy_install setuptools==dev" in a windows box but have an error with svn command. """... 'svn' is not recognized as an internal or external command, ...""" I have installed TortoiseSVN but it seems that don't have command line, is all with the Explorer. Can you tell me what client I may use in windows? Thanks for all, Helio Pereira Sharky @ PTNet

3 2

local development scenarios
by tgreenwood April 29, 2018

April 29, 2018

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm new to distutils/and the egg system. I have not researched the archives as much as I should, so please excuse me if this is familiar territory... Q: Is it possible for dependency checks to work for non pipy deployed eggs? - A.egg - B.egg (setup_requires and install_requires A.egg) - email A and B eggs to friend - tell friend to : easy_install B - but B.egg does not install A...in fact, in my test case, it fails b/c it cannot find A in pipy - in this example, what happens if friend does not have net connection on target machine? how can they install from the eggs alone and get the dep checking to work? Q: How does my friend run the unittests on the egg that they have just installed? As I am developing, I frequently run the unittests and after every bdist_egg build, I also run the unit tests that way, too. How can the consumer do the same? Q: One of my apps is a command line app, say foo.py is a command line app that takes arg1, arg2,... How can the user run this app when it is encased in an egg? Q: How do I define my own pipy? While I like the idea of deploying there for the overall community, I don't want to send my half baked code into the wild. But I'd like to try the general functionality of having a deploy site for my beta customers. How can I set this up? Thanks in advance. - -Todd -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDl9Hfz6uXX4lQc/URAnY4AJ47DFHL/cpEltmqoUyGqzhsK5FjRACgt01v akc3Wh3IOXVv2jiS8TszhuE= =Rv/x -----END PGP SIGNATURE-----

5 12

Choice of dependencies?
by John J Lee April 29, 2018

April 29, 2018

Is it possible for a package to depend on one of several packages, with the user having the option to pick? For example, my package P might depend on package A, plus either package B or package C. I know I could (ab)use extras_require, but in my case this is a real dependency rather than an optional extra. The other option I have is to just pick one of the dependencies (B or C in my example above), and thereby force people to install it even though it's not strictly required. Neither option seems particularly attractive. John

3 6

setuptools doc patch
by John J Lee April 29, 2018

April 29, 2018

The comma removed by the patch below implies that users working from a Subversion checkout should not use EasyInstall to periodically fetch the latest version. That's not what you intended to say, I assume? http://peak.telecommunity.com/DevCenter/setuptools You should also inform your users of the need to run this command, if they -are working from a Subversion checkout, rather than using EasyInstall to +are working from a Subversion checkout rather than using EasyInstall to periodically fetch the latest version. Hmm, probably much better than the patch above: -You should also inform your users of the need to run this command, if they -are working from a Subversion checkout, rather than using EasyInstall to -periodically fetch the latest version. +If your users are working from a Subversion checkout rather than using +EasyInstall, you should also inform them of the need to run this command +to periodically fetch the latest version. John

2 2

Re: [Distutils] distutils install probs on suse 9.0
by Mats Wichmann April 29, 2018

April 29, 2018

At 05:43 AM 5/18/2004, David Handy wrote: >On Tue, 18 May 2004, Floris van der Tak wrote: > >> my attempt to install the distutils on suse 9.0 (which provides python >> 2.3) fails: > >Why are you installing distutils on a system that already has Python 2.3 >installed? Python 2.3 normally comes with distutils as part of the Python >standard library. > >Did suse distribute a version of Python that had distutils removed? It should come from python-devel

2 1

Sample setup.py for Numeric Python
by Greg Ward April 29, 2018

April 29, 2018

Hi again -- [cc'd to Paul Dubois: you said you weren't following the distutils sig anymore, but this directly concerns NumPy and I'd like to get your input!] here's that sample setup.py for NumPy. See below for discussion (and questions!). ------------------------------------------------------------------------ #!/usr/bin/env python # Setup script example for building the Numeric extension to Python. # This does sucessfully compile all the .dlls. Nothing happens # with the .py files currently. # Move this file to the Numerical directory of the LLNL numpy # distribution and run as: # python numpysetup.py --verbose build_ext # # created 1999/08 Perry Stoll __rcsid__ = "$Id: numpysetup.py,v 1.1 1999/09/12 20:42:48 gward Exp $" from distutils.core import setup setup (name = "numerical", version = "0.01", description = "Numerical Extension to Python", url = "http://www.python.org/sigs/matrix-sig/", ext_modules = [ ( '_numpy', { 'sources' : [ 'Src/_numpymodule.c', 'Src/arrayobject.c', 'Src/ufuncobject.c' ], 'include_dirs' : ['./Include'], 'def_file' : 'Src/numpy.def' } ), ( 'multiarray', { 'sources' : ['Src/multiarraymodule.c'], 'include_dirs' : ['./Include'], 'def_file': 'Src/multiarray.def' } ), ( 'umath', { 'sources': ['Src/umathmodule.c'], 'include_dirs' : ['./Include'], 'def_file' : 'Src/umath.def' } ), ( 'fftpack', { 'sources': ['Src/fftpackmodule.c', 'Src/fftpack.c'], 'include_dirs' : ['./Include'], 'def_file' : 'Src/fftpack.def' } ), ( 'lapack_lite', { 'sources' : [ 'Src/lapack_litemodule.c', 'Src/dlapack_lite.c', 'Src/zlapack_lite.c', 'Src/blas_lite.c', 'Src/f2c_lite.c' ], 'include_dirs' : ['./Include'], 'def_file' : 'Src/lapack_lite.def' } ), ( 'ranlib', { 'sources': ['Src/ranlibmodule.c', 'Src/ranlib.c', 'Src/com.c', 'Src/linpack.c', ], 'include_dirs' : ['./Include'], 'def_file' : 'Src/ranlib.def' } ), ] ) ------------------------------------------------------------------------ First, what d'you think? Too clunky and verbose? Too much information for each extension? I kind of think so, but I'm not sure how to reduce it elegantly. Right now, the internal data structures needed to compile a module are pretty obviously exposed: is this a good thing? Or should there be some more compact form for setup.py that will be expanded later into the full glory we see above? I've already made one small step towards reducing the amount of cruft by factoring 'include_dirs' out and supplying it directly as a parameter to 'setup()'. (But that needs code not in the CVS archive yet, so I've left the sample setup.py the same for now.) The next thing I'd like to do is get that damn "def_file" out of there. To support it in MSVCCompiler, there's already an ugly hack that unnecessarily affects both the UnixCCompiler and CCompiler classes, and I want to get rid of that. (I refer to passing the 'build_info' dictionary into the compiler classes, if you're familiar with the code -- that dictionary is part of the Distutils extension-building system, and should not propagate into the more general compiler classes.) But I don't want to give these weird "def file" things standing on the order of source files, object files, libraries, etc., because they seem to me to be a bizarre artifact of one particular compiler, rather than something present in a wide range of C/C++ compilers. Based on the NumPy model, it seems like there's a not-too-kludgy way to handle this problem. Namely: if building extension "foo": if file "foo.def" found in same directory as "foo.c" add "/def:foo.def" to MSVC command line this will of course require some platform-specific code in the build_ext command class, but I figured that was coming eventually, so why put it off? ;-) To make this hack work with NumPy, one change would be necessary: rename Src/numpy.def to Src/_numpy.def to match Src/_numpy.c, which implements the _numpy module. Would this be too much to ask of NumPy? (Paul?) What about other module distributions that support MSVC++ and thus ship with "def" files? Could they be made to accomodate this scheme? Thanks for your feedback -- 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

4 5

Can now compile simple extensions
by Greg Ward April 29, 2018

April 29, 2018

Hi all -- at long last, I found the time to hack in the ability to compile extension modules to the Distutils. Mainly, this meant adding a 'build_ext' command which uses a CCompiler instance for all its dirty work. I also had to add a few methods to CCompiler (and, of course, UnixCCompiler) to make this work. And I added a new module, 'spawn', which takes care of running sub-programs more efficiently and robustly (no shell involved) than os.system. That's needed, obviously, so we can run the compiler! If you're in the mood for grubbing over raw source code, then get the latest from CVS or download a current snapshot. See http://www.python.org/sigs/distutils-sig/implementation.html for a link to the code snapshot. I'm still waiting for more subclasses of CCompiler to appear. At the very least, we're going to need MSVCCompiler to build extensions on Windows. Any takers? Also, someone who knows the Mac, and how to run compilers programmatically there, will have to figure out how to write a Mac-specific concrete CCompiler subclass. The spawn module also needs a bit of work to be portable. I suspect that _win32_spawn() (the intended analog to my _posix_spawn()) will be easy to implement, if it even needs to go in a separate function at all. It looks from the Python Library documentation for 1.5.2 that the os.spawnv() function is all we need, but it's a bit hard to figure out just what's needed. Windows wizards, please take a look at the 'spawn()' function and see if you can make it work on Windows. As for actually compiling extensions: well, if you can figure out the build_ext command, go ahead and give it a whirl. It's a bit cryptic right now, since there's no documentation and no example setup.py. (I have a working example at home, but it's not available online.) If you feel up to it, though, see if you can read the code and figure out what's going on. I'm just hoping *I'll* be able to figure out what's going on when I get back from the O'Reilly conference next week... ;-) Enjoy -- 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

2 1

Two fixes (at last)
by Greg Ward April 29, 2018

April 29, 2018

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

2 1

Package versioning
by Timothy Docker April 29, 2018

April 29, 2018

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

3 2

[Distutils-sig] distutils charter and interscript
by John Skaller April 29, 2018

April 29, 2018

3 2

error in windows 7 installation
by Manuel López May 13, 2014

May 13, 2014

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

2 1

PEP 386 and git versioning scheme
by Manlio Perillo Feb. 17, 2013

Feb. 17, 2013

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi. In a project I'm working on, I use git, and I'm trying to follow the versioning scheme used by the git project (since it is very pratical). To summarize, git version is generated from the output of "git describe" command, replacing the '-' character with '.'. git describe returns a string formed by using the most recent tag (e.g. 1.8.1, 1.8.1.rc1), and adding the number of revisions after that tag, and the short ID of the current revision (e.g v1.8.1-301-ga0df26f). So, a version may be something like: v1.8.1.301.ga0df26f It seems that this versioning scheme is not compatible with PEP 386 "new versioning scheme". Is this true? Thanks Manlio Perillo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEGwaYACgkQscQJ24LbaUT1dQCcD0iaA7NSMJIIXX907VQUyoOH LGQAnixPvzjCfSRaWAONy+cVrDPjXpoK =ooSg -----END PGP SIGNATURE-----

4 4

Proposal for incorporating buildout-versions on buildout (Re: Better version pinning in buildout (buildout-versions))
by Jim Fulton Feb. 15, 2013

Feb. 15, 2013

On Sat, Jan 5, 2013 at 5:47 PM, Jim Fulton <jim(a)zope.com> wrote: ... > I propose that buildout-versions get incorporated into > buildout in the following way: OK, proposal 1 wasn't accepted. Here's another stab: Proposal 2 ---------- 1. The ``allow-picked-versions`` option gets a new allowed value of ``show``. if there are unpicked versions and this option is set to ``show``, then picked/unpinned versions are reported in a way suitable for copying into a versions section, presumably with the same format used by buildout-versions today. 2. New buildout option: ``update-versions-file``. This takes a path (relative to buildout directory) of a file to update with any unpinned versions (in a manner roughly the same as buildout-versions does today). 3. New buildout option: ``python-version`` that restricts the Python version, with the same semantics as buildout-version provides now. 4. Change: develop eggs found in the buildout's develop-eggs directory will be used even if their version conflicts with a pinned version. 5. In buildout 2, The default value of the versions option will be "versions", rather than being unset. This will allow users to omit:: version = versions from their buildout section. 6. To make it a little easier to supply buildout versions on the command line, make buildout the default section for command-line options, so:: update-versions-file=versions.cfg or:: allow-picked-versions=show would be allowed. (They are rejected now.) Thoughts? Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm

10 29

mebs, the meta-build system
by Daniel Holth Feb. 6, 2013

Feb. 6, 2013

or, removing distutils without replacing it. ** not an actual project ** Proposing mebs, the meta-build system. What if pip did not depend on setuptools or distutils and the stdlib did not include distutils or any other build system? Instead, the installer can only install binary packages, and build systems do not install but only build binary packages. A very simple meta-build system "mebs" is used to recognize sdists and build binary packages. Build systems provide plugins having three methods, .recognize() .metadata() .build() An installer downloads an sdist. For each installed build plugin, .recognize(dir) is called. The first plugin to return True is used. The plugin's .metadata(dir) is called, returning Metadata 1.3+ format metadata in a simple email.parser.Parser() multi-dict interface. Used to fetch any build/install requirements. .build(dir) is called to create the binary package. The installer installs the binary package. The first time you download an sdist, the build system/installer has to download a pre-built binary package of distutils (because it has been removed from the standard library). Alternatively a minimal setup.cfg build_system=x is consulted to download something other than distutils, the newly installed build plugin recognizes the sdist, and the package is built and installed. You wouldn't have to actually remove distutils, but every other build system could be made to compete with it on equal footing. Binary packages are used as the lingua franca because, unlike build systems, binary packages are simple enough that there can be multiple compatible implementations.

4 5

Review of latest draft of PEP 426 (Python package metadata v1.3)
by Nick Coghlan Feb. 3, 2013

Feb. 3, 2013

I am close to accepting the latest draft of PEP 426 as v1.3 of the package metadata standard. However, while I agree the current requirement that version numbers *must* be in PEP 386 format needs to be relaxed, I don't think the text as written quite achieves that. 1. The "Version" field description should refer to the "Version Specifiers" section rather than directly to PEP 386 2. The version format flexibility must also be addressed in the "Version Specifiers" section (it currently still mandates PEP 386) 3. There needs to be a mechanism to inform automated tools of the *right* version ordering to use, with PEP 386 being the default. 4. A new version numbering scheme shouldn't require a new metadata version As a simple proposal: a new "Version-Scheme" field, with currently supported values "setuptools" and "pep386", and a clause allowing future "pepXYZ" versioning schemes. The version scheme field then effectively defines how versions are sorted for ordered comparisons involving that distribution. (Sorry Daniel, I know it's annoying to have official acceptance of the changes you were originally interested in held up by an unrelated problem, but it makes sense to fix this now, rather than letting the ambiguity persist) I also noticed a couple of minor editing tweaks that are needed: Under the "Fields" heading: s/The fields may appear in any order within the file./The fields may appear in any order within the header section of the file./ Under "Requires-External": s/there's is/there is/ Regards, Nick. P.S. Today I learned that 'chili' is the US spelling of 'chilli' -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

7 36

I can't manage to install pyScss with buildout, buildout don't use entry point configuration of pyScss package
by Stéphane Klein Feb. 1, 2013

Feb. 1, 2013

Hi, I try to use pyScss with buildout but not success : $ cat buildout.cfg [buildout] parts = pyscss [pyscss] recipe = z3c.recipe.scripts eggs = pyScss $ python bootstrap.py $ bin/buildout $ ls bin buildout pyscss $ bin/pyscss Traceback (most recent call last): File "bin/pyscss", line 20, in <module> sys.exit(scss.main()) AttributeError: 'module' object has no attribute 'main' Why buildout didn't use this entry point configuration ? https://github.com/Kronuz/pyScss/blob/master/setup.py#L109 I did a mistake in my buildout.cfg ? Best regards, Stephane

2 1

I wonder what is the best practice to clean a buildout project ?
by Stéphane Klein Jan. 31, 2013

Jan. 31, 2013

Hi, I wonder what is the best practice to clean a buildout project ? I would like a command to remove : * bin/ * develop-eggs * parts * .installed.cfg I can create a Makefile clean, or clean.sh script. What do you do in your project ? Best regards, Stephane -- Stéphane Klein <contact(a)stephane-klein.info> blog: http://stephane-klein.info Twitter: http://twitter.com/klein_stephane cv: http://cv.stephane-klein.info http://www.usenet-fr.net/fur/usenet/repondre-sur-usenet.html http://fr.wikipedia.org/wiki/TOFU_(Usenet_et_Internet)

6 5

PEP-427: Wheel
by Daniel Holth Jan. 31, 2013

Jan. 31, 2013

Here's the wheel pep itself again. I think the prose is precise enough but it could be more clear. My goal is to get these PEPs accepted so the pip maintainers will be willing to merge the waiting "pip can install wheel" branch. It's not perfect, it's extensible. PEP: 427 Title: The Wheel Binary Package Format 0.1 Version: $Revision$ Last-Modified: $Date$ Author: Daniel Holth <dholth(a)fastmail.fm> BDFL-Delegate: Nick Coghlan <ncoghlan(a)gmail.com> Discussions-To: <distutils-sig(a)python.org> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 20-Sep-2012 Post-History: Abstract ======== This PEP describes a built-package format for Python called "wheel". A wheel is a ZIP-format archive with a specially formatted file name and the ``.whl`` extension. It contains a single distribution nearly as it would be installed according to PEP 376 with a particular installation scheme. A wheel file may be installed by simply unpacking into site-packages with the standard 'unzip' tool, while preserving enough information to spread its contents out onto their final paths at any later time. Note ==== This draft PEP describes version 0.1 of the "wheel" format. When the PEP is accepted, the version will be changed to 1.0. (The major version is used to indicate potentially backwards-incompatible changes to the format.) Rationale ========= Python needs a package format that is easier to install than sdist. Python's sdist packages are defined by and require the distutils and setuptools build systems, running arbitrary code to build-and-install, and re-compile, code just so it can be installed into a new virtualenv. This system of conflating build-install is slow, hard to maintain, and hinders innovation in both build systems and installers. Wheel attempts to remedy these problems by providing a simpler interface between the build system and the installer. The wheel binary package format frees installers from having to know about the build system, saves time by amortizing compile time over many installations, and removes the need to install a build system in the target environment. Details ======= Installing a wheel 'distribution-1.0.py32.none.any.whl' ------------------------------------------------------- Wheel installation notionally consists of two phases: - Unpack. a. Parse ``distribution-1.0.dist-info/WHEEL``. b. Check that installer is compatible with Wheel-Version. Warn if minor version is greater, abort if major version is greater. c. If Root-Is-Purelib == 'true', unpack archive into purelib (site-packages). d. Else unpack archive into platlib (site-packages). - Spread. a. Unpacked archive includes ``distribution-1.0.dist-info/`` and (if there is data) ``distribution-1.0.data/``. b. Move each subtree of ``distribution-1.0.data/`` onto its destination path. Each subdirectory of ``distribution-1.0.data/`` is a key into a dict of destination directories, such as ``distribution-1.0.data/(purelib|platlib|headers|scripts|data)``. The initially supported paths are taken from ``distutils.command.install``. c. If applicable, update scripts starting with ``#!python`` to point to the correct interpreter. d. Update ``distribution-1.0.dist.info/RECORD`` with the installed paths. e. Remove empty ``distribution-1.0.data`` directory. f. Compile any installed .py to .pyc. (Uninstallers should be smart enough to remove .pyc even if it is not mentioned in RECORD.) Recommended installer features '''''''''''''''''''''''''''''' Rewrite ``#!python``. In wheel, scripts are packaged in ``{distribution}-{version}.data/scripts/``. If the first line of a file in ``scripts/`` starts with exactly ``b'#!python'``, rewrite to point to the correct interpreter. Unix installers may need to add the +x bit to these files if the archive was created on Windows. Generate script wrappers. In wheel, scripts packaged on Unix systems will certainly not have accompanying .exe wrappers. Windows installers may want to add them during install. File Format ----------- File name convention '''''''''''''''''''' The wheel filename is ``{distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl``. distribution Distribution name, e.g. 'django', 'pyramid'. version PEP-386 compliant version, e.g. 1.0. build tag Optional build number. Must start with a digit. A tie breaker if two wheels have the same version. Sort as None if unspecified, else sort the initial digits as a number, and the remainder lexicographically. language implementation and version tag E.g. 'py27', 'py2', 'py3'. abi tag E.g. 'cp33m', 'abi3', 'none'. platform tag E.g. 'linux_x86_64', 'any'. For example, ``distribution-1.0-1-py27-none-any.whl`` is the first build of a package called 'distribution', and is compatible with Python 2.7 (any Python 2.7 implementation), with no ABI (pure Python), on any CPU architecture. The last three components of the filename before the extension are called "compatibility tags." The compatibility tags express the package's basic interpreter requirements and are detailed in PEP 425. File contents ''''''''''''' The conents of a wheel file, where {distribution} is replaced with the name of the package, e.g. ``beaglevote`` and {version} is replaced with its version, e.g. ``1.0.0``, consist of: #. ``/``, the root of the archive, contains all files to be installed in ``purelib`` or ``platlib`` as specified in ``WHEEL``. ``purelib`` and ``platlib`` are usually both ``site-packages``. #. ``{distribution}-{version}.dist-info/`` contains metadata. #. ``{distribution}-{version}.data/`` contains one subdirectory for each non-empty install scheme key not already covered, where the subdirectory name is an index into a dictionary of install paths (e.g. ``data``, ``scripts``, ``include``, ``purelib`, ``platlib``). #. Python scripts must appear in ``scripts`` and begin with exactly ``b'#!python'`` in order to enjoy script wrapper generation and ``#!python`` rewriting at install time. They may have any or no extension. #. ``{distribution}-{version}.dist-info/METADATA`` is Metadata version 1.3 (PEP 426) or greater format metadata. #. ``{distribution}-{version}.dist-info/WHEEL`` is metadata about the archive itself:: Wheel-Version: 0.1 Generator: bdist_wheel 0.7 Root-Is-Purelib: true #. Wheel-Version is the version number of the Wheel specification. Generator is the name and optionally the version of the software that produced the archive. Root-Is-Purelib is true if the top level directory of the archive should be installed into purelib; otherwise the root should be installed into platlib. #. A wheel installer should warn if Wheel-Version is greater than the version it supports, and must fail if Wheel-Version has a greater major version than the version it supports. #. Wheel, being an installation format that is intended to work across multiple versions of Python, does not generally include .pyc files. #. Wheel does not contain setup.py or setup.cfg. This version of the wheel specification is based on the distutils install schemes and does not define how to install files to other locations. The layout offers a superset of the functionality provided by the existing wininst and egg binary formats. The .dist-info directory ^^^^^^^^^^^^^^^^^^^^^^^^ #. Wheel .dist-info directories include at a minimum METADATA, WHEEL, and RECORD. #. METADATA is the PEP 426 metadata (Metadata version 1.3 or greater) #. WHEEL is the wheel metadata, specific to a build of the package. #. RECORD is a list of (almost) all the files in the wheel and their secure hashes. Unlike PEP 376, every file except RECORD, which cannot contain a hash of itself, must include its hash. The hash algorithm must be sha256 or better; specifically, md5 and sha1 are not permitted, as signed wheel files rely on the strong hashes in RECORD to validate the integrity of the archive. #. INSTALLER and REQUESTED are not included in the archive. #. RECORD.jws is used for digital signatures. It is not mentioned in RECORD. #. RECORD.p7s is allowed as a courtesy to anyone who would prefer to use s/mime signatures to secure their wheel files. It is not mentioned in RECORD and it is ignored by the official tools. #. During extraction, wheel installers verify all the hashes in RECORD against the file contents. Apart from RECORD and its signatures, installation will fail if any file in the archive is not both mentioned and correctly hashed in RECORD. The .data directory ^^^^^^^^^^^^^^^^^^^ Any file that is not normally installed inside site-packages goes into the .data directory, named as the .dist-info directory but with the .data/ extension:: distribution-1.0.dist-info/ distribution-1.0.data/ The .data directory contains subdirectories with the scripts, headers, documentation and so forth from the distribution. During installation the contents of these subdirectories are moved onto their destination paths. Signed wheel files ------------------ Wheel files include an extended RECORD that enables digital signatures. PEP 376's RECORD is altered to include ``digestname=urlsafe_b64encode_nopad(digest)`` (urlsafe base64 encoding with no trailing = characters) as the second column instead of an md5sum. All possible entries are hashed, including any generated files such as .pyc files, but not RECORD. For example:: file.py,sha256=AVTFPZpEKzuHr7OvQZmhaU3LvwKz06AJw8mT\_pNh2yI,3144 distribution-1.0.dist-info/RECORD,, The signature file(s) RECORD.jws and RECORD.p7s are not mentioned in RECORD at all since they can only be added after RECORD is generated. Every other file in the archive must have a correct hash in RECORD, or the installation will fail. If JSON web signatures are used, one or more JSON Web Signature JSON Serialization (JWS-JS) signatures may be stored in a file RECORD.jws adjacent to RECORD. JWS is used to sign RECORD by including the SHA-256 hash of RECORD as the JWS payload:: { "hash": "sha256=ADD-r2urObZHcxBW3Cr-vDCu5RJwT4CaRTHiFmbcIYY" } If RECORD.p7s is used, it must contain a PKCS#7 format signature of RECORD. A wheel installer may assume that the signature has already been checked against RECORD, and only must verify the hashes in RECORD against the extracted file contents. See - http://self-issued.info/docs/draft-ietf-jose-json-web-signature.html - http://self-issued.info/docs/draft-jones-jose-jws-json-serialization.html - http://self-issued.info/docs/draft-ietf-jose-json-web-key.html - http://self-issued.info/docs/draft-jones-jose-json-private-key.html Comparison to .egg ------------------ #. Wheel is an installation format; egg is importable. Wheel archives do not need to include .pyc and are less tied to a specific Python version or implementation. Wheel can install (pure Python) packages built with previous versions of Python so you don't always have to wait for the packager to catch up. #. Wheel uses .dist-info directories; egg uses .egg-info. Wheel is compatible with the new world of Python packaging and the new concepts it brings. #. Wheel has a richer file naming convention for today's multi-implementation world. A single wheel archive can indicate its compatibility with a number of Python language versions and implementations, ABIs, and system architectures. Historically the ABI has been specific to a CPython release, wheel is ready for the stable ABI. #. Wheel is lossless. The first wheel implementation bdist_wheel always generates egg-info, and then converts it to a .whl. It is also possible to convert existing eggs and bdist_wininst distributions. #. Wheel is versioned. Every wheel file contains the version of the wheel specification and the implementation that packaged it. Hopefully the next migration can simply be to Wheel 2.0. #. Wheel is a reference to the other Python. FAQ === Wheel defines a .data directory. Should I put all my data there? This specification does not have an opinion on how you should organize your code. The .data directory is just a place for any files that are not normally installed inside ``site-packages`` or on the PYTHONPATH. In other words, you may continue to use ``pkgutil.get_data(package, resource)`` even though *those* files will usually not be distributed in *wheel's* ``.data`` directory. Why does wheel include attached signatures? Attached signatures are more convenient than detached signatures because they travel with the archive. Since only the individual files are signed, the archive can be recompressed without invalidating the signature, or individual files can be verified without having to download the whole archive. Appendix ======== Example urlsafe-base64-nopad implementation:: # urlsafe-base64-nopad for Python 3 import base64 def urlsafe_b64encode_nopad(data): return base64.urlsafe_b64encode(data).rstrip(b'=') def urlsafe_b64decode_nopad(data): pad = b'=' * (4 - (len(data) & 3)) return base64.urlsafe_b64decode(data + pad) Copyright ========= This document has been placed into the public domain. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End:

1 0

PEP-425 Compatibility Tags for Build Distributions (wheel prerequisite)
by Daniel Holth Jan. 31, 2013

Jan. 31, 2013

Here's a re-post of PEP 425 "Compatibility Tags for Build Distributions". It belongs to the wheel suite of PEPs: 425 (compatibility tags), 426 (metadata) and 427 (wheel). PEP: 425 Title: Compatibility Tags for Built Distributions Version: $Revision$ Last-Modified: 07-Aug-2012 Author: Daniel Holth <dholth(a)fastmail.fm> BDFL-Delegate: Nick Coghlan <ncoghlan(a)gmail.com> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 27-Jul-2012 Python-Version: 3.4 Post-History: 8-Aug-2012 Abstract ======== This PEP specifies a tagging system to indicate with which versions of Python a built or binary distribution is compatible. A set of three tags indicate which Python implementation and language version, ABI, and platform a built distribution requires. The tags are terse because they will be included in filenames. PEP Editor's Note ================= While the naming scheme described in this PEP will not be supported directly in the standard library until Python 3.4 at the earliest, draft implementations may be made available in third party projects. Rationale ========= Today "python setup.py bdist" generates the same filename on PyPy and CPython, but an incompatible archive, making it inconvenient to share built distributions in the same folder or index. Instead, built distributions should have a file naming convention that includes enough information to decide whether or not a particular archive is compatible with a particular implementation. Previous efforts come from a time where CPython was the only important implementation and the ABI was the same as the Python language release. This specification improves upon the older schemes by including the Python implementation, language version, ABI, and platform as a set of tags. By comparing the tags it supports with the tags listed by the distribution, an installer can make an educated decision about whether to download a particular built distribution without having to read its full metadata. Overview ======== The tag format is {python tag}-{abi tag}-{platform tag} python tag â€˜py27â€™, â€˜cp33â€™ abi tag â€˜cp32dmuâ€™, â€˜noneâ€™ platform tag â€˜linux_x86_64â€™, â€˜anyâ€™ For example, the tag py27-none-any indicates compatible with Python 2.7 (any Python 2.7 implementation) with no abi requirement, on any platform. Use === The `wheel` built package format includes these tags in its filenames, of the form ``{distribution}-{version}(-{build tag})?-{python tag}-{abi tag}-{platform tag}.whl``. Other package formats may have their own conventions. Details ======= Python Tag ---------- The Python tag indicates the implementation and version required by a distribution. Major implementations have abbreviated codes, initially: * py: Generic Python (does not require implementation-specific features) * cp: CPython * ip: IronPython * pp: PyPy * jy: Jython Other Python implementations should use `sys.implementation.name`. The version is `py_version_nodot`. CPython gets away with no dot, but if one is needed the underscore `_` is used instead. PyPy should probably use its own versions here `pp18`, `pp19`. The version can be just the major version `2` or `3` `py2`, `py3` for many pure-Python distributions. Importantly, major-version-only tags like `py2` and `py3` are not shorthand for `py20` and `py30`. Instead, these tags mean the packager intentionally released a cross-version-compatible distribution. A single-source Python 2/3 compatible distribution can use the compound tag `py2.py3`. See `Compressed Tag Sets`, below. ABI Tag ------- The ABI tag indicates which Python ABI is required by any included extension modules. For implementation-specific ABIs, the implementation is abbreviated in the same way as the Python Tag, e.g. `cp33d` would be the CPython 3.3 ABI with debugging. The CPython stable ABI is `abi3` as in the shared library suffix. Implementations with a very unstable ABI may use the first 6 bytes (as 8 base64-encoded characters) of the SHA-256 hash of ther source code revision and compiler flags, etc, but will probably not have a great need to distribute binary distributions. Each implementation's community may decide how to best use the ABI tag. Platform Tag ------------ The platform tag is simply `distutils.util.get_platform()` with all hyphens `-` and periods `.` replaced with underscore `_`. * win32 * linux_i386 * linux_x86_64 Use === The tags are used by installers to decide which built distribution (if any) to download from a list of potential built distributions. The installer maintains a list of (pyver, abi, arch) tuples that it will support. If the built distribution's tag is `in` the list, then it can be installed. For example, an installer running under CPython 3.3 on a linux_x86_64 system might support:: 1. cp33-cp33m-linux_x86_64 2. cp33-abi3-linux_x86_64 3. cp33-none-linux_x86_64 4. cp33-none-any 5. cp3-none-any 6. cp32-none-any 7. cp31-none-any 8. cp30-none-any 9. py33-none-any 10. py3-none-any 11. py32-none-any 12. py31-none-any 13. py30-none-any The list is in order from most-preferred (a distribution with a compiled extension module, built for the current version of Python) to least-preferred (a pure-Python distribution built with an older version of Python). A user could instruct their installer to fall back to building from an sdist more or less often by configuring this list of tags; for example, a user could include only the `*-none-any` tags to only download built packages that advertise themselves as being pure Python. Rarely there will be more than one supported built distribution for a particular version of a package. For example, a packager could release a package tagged `cp33-abi3-linux_x86_64` that contains an optional C extension and the same distribution tagged `py3-none-any` that does not. The index of the tag in the supported tags list breaks the tie, and the package with the C extension is installed in preference to the package without because that tag appears first in the list. Compressed Tag Sets =================== To allow for compact filenames of bdists that work with more than one compatibility tag triple, each tag in a filename can instead be a '.'-separated, sorted, set of tags. For example, pip, a pure-Python package that is written to run under Python 2 and 3 with the same source code, could distribute a bdist with the tag `py2.py3-none-any`. The full list of simple tags is:: for x in pytag.split('.'): for y in abitag.split('.'): for z in archtag.split('.'): yield '-'.join((x, y, z)) A bdist format that implements this scheme should include the expanded tags in bdist-specific metadata. This compression scheme can generate large numbers of unsupported tags and "impossible" tags that are supported by no Python implementation e.g. "cp33-cp31u-win64", so use it sparingly. FAQ === What tags are used by default? Tools should use the most-preferred architecture dependent tag e.g. `cp33-cp33m-win32` or the most-preferred pure python tag e.g. `py33-none-any` by default. If the packager overrides the default it indicates that they intended to provide cross-Python compatibility. Can I have a tag `py32+` to indicate a minimum Python minor release? No. Inspect the Trove classifiers to determine this level of cross-release compatibility. Similar to the announcements "beaglevote versions 3.2 and above no longer supports Python 1.52", you will have to manually keep track of the maximum (PEP-386) release that still supports your version of Python. Why isn't there a `.` in the Python version number? CPython has lasted 20+ years without a 3-digit major release. This should continue for some time. Other implementations may use _ as a delimeter, since both - and . delimit the surrounding filename. Who will maintain the registry of abbreviated implementations? New two-letter abbreviations can be requested on the python-dev mailing list. As a rule of thumb, abbreviations are reserved for the current 4 most prominent implementations. Does the compatibility tag go into METADATA or PKG-INFO? No. The compatibility tag is part of the built distribution's metadata. METADATA / PKG-INFO should be valid for an entire distribution, not a single build of that distribution. Why didn't you mention my favorite Python implementation? The abbreviated tags facilitate sharing compiled Python code in a public index. Your Python implementation can use this specification too, but with longer tags. Recall that all "pure Python" built distributions just use 'py'. References ========== .. [1] Egg Filename-Embedded Metadata ( http://peak.telecommunity.com/DevCenter/EggFormats#filename-embedded-metada… ) .. [2] Creating Built Distributions (http://docs.python.org/distutils/builtdist.html) .. [3] PEP 3147 -- PYC Repository Directories (http://www.python.org/dev/peps/pep-3147/) Acknowledgements ================ The author thanks Paul Moore, Nick Coghlan, Mark Abramowitz, and Mr. Michele Lacchia for their valuable advice and help with this effort. Copyright ========= This document has been placed in the public domain. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End:

1 0

A new script which creates Python 3.3 venvs with Distribute and pip installed in them
by Vinay Sajip Jan. 31, 2013

Jan. 31, 2013

Python 3.3 includes a script, pyvenv, which is used to create virtual environments. However, Distribute and pip are not installed in such environments - because, though they are popular, they are third-party packages - not part of Python. The Python 3.3 venv machinery allows customisation of virtual environments fairly readily. To demonstrate how to do this, and to provide at the same time a script which might be useful to people, I've created a script, pyvenvex.py, at https://gist.github.com/4673395 which extends the pyvenv script to not only create virtual environments, but to also install Distribute and pip into them. The script needs Python 3.3, and one way to use it is: 1. Download the script to a directory in your path, and (on Posix platforms) make it executable. 2. Add a shebang line at the top of your script, pointing to your Python 3.3 interpreter (Posix, and also Windows if you have the PEP 397 launcher which is part of Python 3.3 on Windows). 3. Run the pyvenvex script to create your virtual environments, in place of pyvenv, when you want Distribute and pip to be installed for you (this is how virtualenv sets up environments it creates). You can run the script with -h to see the command line options available, which are a superset of the pyvenv script. Regards, Vinay Sajip

4 3

Re: [Distutils] Support for condition to include or exclude a buildout sections based on a Python expression
by Philippe Ombredanne Jan. 30, 2013

Jan. 30, 2013

> On Wed, Jan 30, 2013 at 4:52 PM, Philippe Ombredanne > <pombredanne(a)nexb.com> wrote: >> On Wed, Jan 30, 2013 at 4:53 PM, Leonardo Rochael Almeida >> <leorochael(a)gmail.com> wrote: >>> Also, it would be nice to have this info on the output of "buildout annotate" >> I am not sure this would be possible as the sections are skipped >> before annotating On Wed, Jan 30, 2013 at 8:42 PM, Leonardo Rochael Almeida <leorochael(a)gmail.com> wrote: > If they're skipped before annotating, but the ones that remain on > "annotate" are the ones that would be run, and they include the > conditional info, then that's Good Enough For Me (TM) :-) this is exactly the behavior ;) -- Philippe Ombredanne +1 650 799 0949 | pombredanne(a)nexB.com DejaCode Enterprise at http://www.dejacode.com nexB Inc. at http://www.nexb.com

1 0

Support for condition to include or exclude a buildout sections based on a Python expression
by Philippe Ombredanne Jan. 30, 2013

Jan. 30, 2013

All: I prepared a pull request https://github.com/buildout/buildout/pull/51 to add support in Buildout 2 for conditional sections expressions. The gist of this is explained here: Sections headers can contain an optional arbitrary Python expression. When the expression evaluates to false the whole section is skipped. Several sections can have the same name with different expressions, enabling conditional exclusion of sections. For instance using simple expressions you can get this done: # this expression is true, so the section is included [s1: 2 + 2 == 4] a = 1 # this expression is false, so the section s2 is skipped [s2 : 2 + 2 == 5 ] long = a # Complex expressions are possible, though they should not be abused :) and they need to fit on a single line [s3:2 in map(lambda i:i*2, [i for i in range(10)])] long = c One of the typical usage is to have buildout parts that are operating system or plaform specific, such as defining eggs that may run only on one os (such as readline only for Macosx and pyreadline only for Windows.). There some convenience defaults conditionals pre-computed as well as some default modules available to an expression to support this: [install_eggs: windows] recipe = zc.recipe.egg eggs = pyreadline and [install_eggs: macosx] recipe = zc.recipe.egg eggs = readline ... become possible and only the right section will be included. The limited (but hopefully sane and sufficient) set of default modules and precomputed common expressions are: # available modules sys, re, os and platfrom should cover most of the common cases [s1: sys and re and os and platform] # major and minor python versions, yes even python 3.5 and 3.6 are there, prospectively [s2: any([python2, python3, python24 , python25 , python26 , python27 , python30 , python31 , python32 , python33 , python34 , python35 , python36]) ] # common python interpreter types [s3: cpython or pypy or jython or ironpython] # common operating systems [s4: linux or windows or cygwin or macosx or solaris or posix ] # common bitness and endianness [s5: bits32 or bits64 or little_endian or big_endian] Some other points: - expression are evaluated _during parsing_ of a cfg file, so before interpolation, hence variable substitution are not possible... we could populate the expression context with a copy of the current state of the buildout object to provide some limited access to some of the buildout options and sections that are already known at the parsing time.. - security could be a concern, but hey if you are running buildout you are already letting run arbitrary code and recipes downloaded live from unknown sources, so I do not think this is a big concern. - if you do not use expressions in your buildout, there is no impact at all. Feedback on the code and features is welcomed... ATM the code is ready to pull in and all the tests are passing -- Philippe Ombredanne +1 650 799 0949 | pombredanne(a)nexB.com DejaCode Enterprise at http://www.dejacode.com nexB Inc. at http://www.nexb.com

4 6

PEP-426 environment markers [was: Re: Support for condition to include or exclude a buildout sections based on a Python expression]
by Philippe Ombredanne Jan. 30, 2013

Jan. 30, 2013

On Wed, Jan 30, 2013 at 1:39 PM, Jim Fulton <jim(a)zope.com> wrote: > On Tue, Jan 29, 2013 at 6:25 PM, Nick Coghlan <ncoghlan(a)gmail.com> wrote: >> On Wed, Jan 30, 2013 at 12:02 AM, Philippe Ombredanne >> <pombredanne(a)nexb.com> wrote: >>> All: >>> >>> I prepared a pull request https://github.com/buildout/buildout/pull/51 >>> to add support in Buildout 2 for conditional sections expressions. >> >> If you're going to do something like this, it would be good to base it >> on PEP 345/426 style "environment markers", which are basically the >> same idea applied to dependency definitions in the package metadata: >> http://www.python.org/dev/peps/pep-0426/#environment-markers > > I think it makes sense to support these markers. This is rather easy with a caveat: http://www.python.org/dev/peps/pep-0426/#environment-markers defines markers EXPR as one of these: python_version = '%s.%s' % (sys.version_info[0], sys.version_info[1]) python_full_version = sys.version.split()[0] os.name = os.name sys.platform = sys.platform platform.version = platform.version() platform.machine = platform.machine() platform.python_implementation = platform.python_implementation() a free string, like '2.4', or 'win32' extra = (name of requested feature) or None A python implementation of the proposed draft would have to monkey patch standard functions (platform.version, platform.machine and platform.python_implementation) with their invocation results or would require rather complex parsing..... Since this is a draft, could we instead avoid a module-like syntax for all EXPR and instead use this: python_version = '%s.%s' % (sys.version_info[0], sys.version_info[1]) python_full_version = sys.version.split()[0] os_name = os.name sys_platform = sys.platform platform_version = platform.version() platform_machine = platform.machine() platform_python_implementation = platform.python_implementation() a free string, like '2.4', or 'win32' extra = (name of requested feature) or None This sounds more consistent to me to replace the dots with _ consistently the same way the original python_version has been specified Also, platform.python_implementation() is new in Python 2.6 .... so this could not run on 2.5 or 2.5 .... even though the PEP alludes to support of 2.4 and 2.5 This is not an issue for Buildout 2.0, but could be for the PEP -- Philippe Ombredanne +1 650 799 0949 | pombredanne(a)nexB.com DejaCode Enterprise at http://www.dejacode.com nexB Inc. at http://www.nexb.com

4 9

pip and distutils
by Vraj Mohan Jan. 30, 2013

Jan. 30, 2013

---------- Forwarded message ---------- From: Vraj Mohan <r.vrajmohan(a)gmail.com> Date: Mon, Jan 28, 2013 at 4:31 PM Subject: pip and distutils To: python-list(a)python.org I have created a source distribution using distutils which specifies external packages using: setup( ..., requires = ['Foo (>= 0.7)', 'Bar (>= 2.4.5)'], ... ) When I use pip to install this distribution, I find that it does not automatically install the packages Foo and Bar. What extra step do I need to perform to have pip automatically install the "required" packages? I am using Python 3.2.3. --Vraj

3 3

Confused by setuptools, distribute, disutils and distutils2
by Vraj Mohan Jan. 29, 2013

Jan. 29, 2013

Hi, I hope this is the right forum for this question. I asked a related question in python-list but got no response. I am new to building packages and am using Python 3.2.3. If I need to build a package that depends on other packages installed in PyPI, what should I use? If I follow http://packages.python.org/distribute/setuptools.html#developer-s-guide, it says install setuptools first. If I read the Hitchhiker's guide (http://guide.python-distribute.org/installation.html), it says that "Distribute was created because the Setuptools package is no longer maintained". Please let me know if there is a single document that I should follow. As I am working on Python 3.2.3, I am not interested in historical Python2 information. Also, if life is better with Python 3.3, as promised in the Hitchhiker's guide, please let me know and I'll move to it. Thanks, Vraj Mohan

2 1

Re: [Distutils] Review of latest draft of PEP 426 (Python packageetadata v1.3)
by a.cavallo＠cavallinux.eu Jan. 29, 2013

Jan. 29, 2013

I never quite understood what 1.2beta ever meant in a typical life cycle in first. Source code *has* a natural sequential evolution nature (call it a commit time stamp, a scm version number etc.): even branches can be seen sequential walk along a "timeline". For that reason I don't think enforcing a __release__ tag being a let's say 3 non decreasing digit would be a bad idea: "rebels" willing to use things like 1.2b can keep still stuff that in (IMHO) the wrong __version__ variable. If __release__ is not defined it can default to 0.0.0 (so holding the backward compatibility. On Tue 29/01/13 11:25, "Vinay Sajip" vinay_sajip(a)yahoo.co.uk wrote: > Daniel Holth <dholth <at> gmail.com> writes: > > > It hurts to have multiple version schemes in > concurrent use. > Agreed, but I don't see how you can avoid it; even if all projects switch > over to a single scheme in the future, you still have the problem of past > versions. You can be sure, too, that for many projects, their dependencies will > use schemes which may not be mutually compatible with each other (excepting, > of course, if you treat them all as having the "legacy" version scheme - that, > of course, fits everything, as it is sufficiently liberal). > > Regards, > > Vinay Sajip > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG(a)python.org > http://mail.python.org/mailman/listinfo/distutils-sig > >

1 0

[RFC] support configure + make pattern in distutils (or setuptools)
by Manlio Perillo Jan. 28, 2013

Jan. 28, 2013

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi. Recently I have started a new project that needs some runtime configuration. All the open sources projects I have reviewed, do the configuration step by usually deriving from the build_ext command class, and then execute some configuration code to set required options. This result in what I believe is bad design, and in some cases the setup.py ends up in a unreadable mess of code. I think that the setup.py should be as much as declarative as possible. I have studied the distutils source code, where I found a config command. Unfortunately this command is never used by other commands, e.g., the build_ext does not call self.set_undefined_options('config', ...) Another problem is that you have to do something like this: $ python setup.py \ config --pg_config=/usr/local/pgsql/bin/pg_config \ build every time you need to build code (e.g. during development). This is the reason a decided to write an "improved" config command; I have attached a sample implementation. The new config command does the following: If config.dat (adjacent to setup.py file) does not exists, or if user has explicitly executed the config command or if setup.cfg is newer than config.dat, then: call the configure method (that user must override), and then save all options to config.dat file, using pickle (XXX the code here is a bit tricky [1]) otherwise, load the config.dat file and set options in the config command instace. This implementation allow users to use the traditional configure + make pattern: $ python setup.py config --pg_config=/usr/local/pgsql/bin/pg_config $ python setup.py build $ sudo python setup.py install (or develop, using setuptools) A project that needs runtime configuration, will create a config.py module (adjacent to setup.py) file, and will define a custom config command, derived from the provided class. The setup.py file will import the config module, and will use the cmdclass setup option to register the new command. The next step is to implement an "improved" build_ext command, that will use options from the config command, as default values. [1] a better solution is to have the configure method return a dictionary, but it is more verbose Feedback is appreciated. Thanks Manlio Perillo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEGihoACgkQscQJ24LbaURAwwCfULYAQg7yOWPzRNFJZ+YobvRG oUkAoIqm43SfWg9AdjurrYqui4tjVWse =PeN3 -----END PGP SIGNATURE-----

3 3

instalar scapy bajo python 3.3.0
by MIGUEL ANGEL FERNANDEZ ANDRES Jan. 28, 2013

Jan. 28, 2013

buenas: me pierdo como, donde se instala scapy para que funcione bajo el programa python version 3.3.0 gracias y saludos:

2 1

[buildout] supported python versions for buildout 2?
by Chris Withers Jan. 24, 2013

Jan. 24, 2013

Hi Jim, What are the supported python versions for Buildout 2? cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

4 3

buildout 2.0.0b1 released
by Jim Fulton Jan. 22, 2013

Jan. 22, 2013

Changes: http://pypi.python.org/pypi/zc.buildout/2.0.0b1#b1-2013-01-21 If problems aren't discovered first, I plan to make the final release next weekend. To install the new release, download: http://downloads.buildout.org/2/bootstrap.py if you haven't already. (It hasn't changed since 2.0.0a6.) Then bootstrap projects with: python bootstrap.py -t Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm

3 11

Re: [Distutils] [buildout] infinite loop when specifying setuptools version on mac
by Chris Withers Jan. 22, 2013

Jan. 22, 2013

On 21/01/2013 09:36, Philippe Ombredanne wrote: > On Sun, Jan 20, 2013 at 9:15 PM, Chris Withers<chris(a)simplistix.co.uk> wrote: >> See the attached .tgz, here's what I did on a mac min running 10.7.4: >> "/Library/Python/2.7/site-packages/setuptools-0.6c12dev_r88846-py2.7.egg/setuptools/package_index.py", Can anyone else with a Mac running 10.7.4 check whether this is how they ship? I'm fairly certain I haven't installed anything globally on that machine, so I'd be surprised and disappointed if the above was my doing... > Try adding this to your buildout: > include-site-packages = false Jim, does this still work in 1.7? I got the impression it was going away at some point... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

3 2

[buildout] windows/jenkins annoyance
by Chris Withers Jan. 21, 2013

Jan. 21, 2013

Hi Jim, This is an example of the Windows problem I was referring to: http://jenkins.simplistix.co.uk/job/testfixtures-buildout/160/PYTHON=2.5,la… C:\Python25\python.exe bootstrap.py ...appears to fork off a process in such a way that it returns instantly and then runs in the background. Of course, Jenkins has no way to know how long to wait for, so problems such as those above occur. My horrible hack around this is: https://github.com/Simplistix/testfixtures/blob/master/jenkins.bat#L2 ...which waits 20 seconds and then moves to the next step. It's far from reliable, especially when the Windows box has any load on it. Can you make any suggestions how to solve this problem? cheers, Chris PS: Where does the buildout continuous integration testing live nowadays? -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

3 11

Re: [Distutils] buildout in offline mode - install receipts also from cache?
by Philippe Ombredanne Jan. 21, 2013

Jan. 21, 2013

On Mon Dec 17 15:35:47 CET 2012, Anton Koval' psihonavt at gmail.com wrote: > in our project we've decided to completely move > buildout process to offline mode. > according to documentation > (http://pypi.python.org/pypi/zc.buildout/2.0.0a5) > I made updates in our main buildout configuration file, like: > download-cache = ... > install-from-cache = true > offline = true > But when buildout tries to install any part with recipe specified, > it is (obviously) failing, e.g.: > Error: Couldn't find a distribution for 'iw.recipe.cmd'. > So, my question is: are there ways to fetch recipes also from > some cache (or whatever) on local disk? I have experienced the same issue See https://github.com/buildout/buildout/issues/41 This is a bug and also per Jim Fulton a lack of specification/documentation of what offline really means. IMHO it is not possible today to bootstrap and buildout offline. Anyone with a better story there? That said the fixes are rather easy ... And I have an ugly but nicely working monkey patching extension that I will publish on pypi in a couple days... Which ironically enough needs to be installed with pip before a boostrap. Now Jim suggested I should bring the discussion here. In general installing packages without a network connection should be straight forward, simple and easy. That would be the common understanding of what offline means. It works fine with setuptools/distribute and pip albeit a tad circumvoluted and under documented. It does not with buildout and fails because with the offline flag/config, buildout calls its install function with a None dest argument making setuptools/distribute fail downstream with a weird exception as you reported. This affects all current and recent versions of buildout. -- Philippe Ombredanne nexB

2 6

[buildout] best bootstrap.py to use for buildout 1.7?
by Chris Withers Jan. 19, 2013

Jan. 19, 2013

Hi All, What's the best bootstrap.py to use for buildout 1.7? I'm excited to say it looks like the bootstrap I currently have at https://github.com/Simplistix/testfixtures/blob/master/bootstrap.py appears to no longer need me to wrap my system pythons in virtualenvs to get bootstrap to work with them. But, is there a newer version that would be better to use? cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

2 1

buildout 2.0.0a7 released, fixes bug in 2.0.0a6.
by Jim Fulton Jan. 12, 2013

Jan. 12, 2013

To install the new release, download: http://downloads.buildout.org/2/bootstrap.py if you haven't already. It hasn't changed since 2.0.0a6. Then bootstrap projects with: python bootstrap.py -t On Fri, Jan 11, 2013 at 6:05 PM, Maurits van Rees <m.van.rees(a)zestsoftware.nl> wrote: ... > It fails when the first non-comment line after a section (even an otherwise > empty section) is blank. Dang. Fixed in 2.0.0a7. You'll need to bootstrap again. You don't need to download a new bootstrap script. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm

2 1

zc.buildout 2.0.0a6 released: updated config-file syntax
by Jim Fulton Jan. 11, 2013

Jan. 11, 2013

I've just released zc.buildout-2.0.0a6. The primary change in this release is that the configuration-file syntax has changed: - Relative indentation in option values is retained if the first line is blank. (IOW, if the non-blank text is on the continuation lines.) As in:: [mysection] tree = /root /branch In such cases, internal blank lines are also retained. - The configuration syntax is more tightly defined, allowing fewer syntax definitions. Buildout 1 configuration files were parsed with the Python ConfigParser module. The ConfigParser module's format is poorly documented and wildly flexible. For example: - Any characters other than left square brackets were allowed in section names. - Arbitrary text was allowed and ignored after the closing bracket on section header lines. - Any characters other than equal signs or colons were allowed in an option name. - Configuration options could be spelled as RFC 822 mail headers (using a colon, rather than an equal sign). - Comments could begin with "rem". - Semicolons could be used to start inline comments, but only if preceeded by a whitespace character. See http://pypi.python.org/pypi/zc.buildout/2.0.0a6#configuration-file-syntax This potentially the most controversial backward-incompatible change in buildout 2, so try it out and let me know if the changes present any serious problems. To get this release you need a new bootstrap file: http://downloads.buildout.org/2/bootstrap.py You also need to use the -t option, because buildout 2 isn't final. (The new bootstrap is needed because I'm not releasing buildout non-final releases to pypi in deference to tools that don't prefer final releases. The bootstrap from 2.0.0a5 can't be used because it uses a github download area and github took away that feature.) Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm

2 1

python-distribute.org domain
by Tarek Ziadé Jan. 11, 2013

Jan. 11, 2013

Hi This domain lives on my server - which can occasionally fall with me not being around. It's a crappy $20/month server. A couple of folks can update it but they don't have a full access on the server. That's where zc.buildout & some other tools grab http://python-distribute.org/distribute_setup.py Maybe it would be smarter to have it in a more reliable place - and with more people being able to manage it. Does anyone have a good idea for this ? If someone has a better solution I can redirect the domain to a new place. Thanks Tarek -- Tarek Ziadé · http://ziade.org · @tarek_ziade

2 4

Merging buildout-versions in buildout
by Chris Withers Jan. 11, 2013

Jan. 11, 2013

Hi All, My take on this, as the person who may or may not have offered to do the work... After reading all the discussion, it sounds like the approach buildout-versions currently takes is the one that's going to give the most milleage: - print the versions picked for any packages (as opposed to being specified by the buildout), in a format compatible with being pasted into buildout.cfg's versions section. This should happen by default. (when *wouldn't* you want this to be shown?) - have a key that points to a file where the text above is appended. It's up to the use whether this is buildout.cfg or not. For myself, if the buildout is tiny, I put a versions section at the end and point this option at buildout.cfg. Otherwise, I point it as a versions.cfg. I had forgotten how important the interaction between the versions section and the extends mechanism was. I've also made great use of this. While I like the idea of a versions format compatible with pip*, it sounds like that would kill off the extends interaction, which would be bad. I'll note that there appears to be no contention over the optional python-version key to stop you accidentally running a buildout with the wrong python. cheers, Chris * I have to admit to currently thinking hard about migrating away from buildout; its development has been hampered by people with not enough time trying to solve hard problems, the dropping of Windows support (yeah, I hate windows too, but its still used enough that I need to support it, unfortunately I'm not competent enough to help with development *of* buildout on Windows). That said, I don't know that pip/virtualenv would be any better. -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

5 8

zc.buildout 1.7.0 released, the don't upgrade to buildout 2 release
by Jim Fulton Jan. 11, 2013

Jan. 11, 2013

See http://pypi.python.org/pypi/zc.buildout/1.7.0 Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm

1 0

Better version pinning in buildout (buildout-versions)
by Jim Fulton Jan. 11, 2013

Jan. 11, 2013

Lots of people agree that buildout-versions us useful and the author has volunteered to contribute it to core buildout. Cool! Of course, as a part of buildout, rather than an extension, it can be streamlined a bit. Also, based on experience, I think we can simplify versions management a bit further. When I implemented the versions mechanism in buildout, I decided to build on the configuration model. This has worked pretty well, especially for complex use cases like layering version specifications (e.g. building on "known good sets"), but this approach has added a little bit of drudgery. Because I didn't want to stomp on existing versions sections, I made the name of the section containing versions require configuration, which means you end up with:: versions = versions [versions] ... I also think it's a little awkward to have buildout update files that are also edited by users. Based on this, I propose that buildout-versions get incorporated into buildout in the following way: 1. New buildout option named ``versions-file`` which takes the name of a file. to contain version information. It is not a configuration file. It is a file consisting of comments (#...) and version specifications:: # whatever foo = 1.3 If it doesn't exist, it wil be created. (I'm not sure it's a good idea to create the file implicitly though.) Any version constraints found in the file are added to the buildout version constraints. Version constraints found in the versions-file override version constraints obtained via a versions option, if any. 2. New buildout option: ``update-versions-file``. If this is true, then any picked/unpinned versions are appended to the versions file and reported in the output. There's a command-line option, ``-V`` to set this to true for a run. It's an error to use this if ``versions-file`` isn't set. 3. The ``allow-picked-versions`` option gets a new allowed value of ``warn``. if there are unpicked versions and this option is set to ``warn``, then picked/unpinned versions are reported. Also, if ``allow-picked-versions`` is true, there will be no error if ``update-versions-file`` is true. 4. New buildout option: ``python-version`` that restricts the Python version, with the same semantics as buildout-version provides now. Thoughts? Did I miss anything? Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm

9 22

pip install --upgrade bug on python3.x
by Christian Tismer Jan. 10, 2013

Jan. 10, 2013

Hi folks, I recognized a glitch with pip when using the --upgrade option. From the traceback: File "./setuptools/dist.py", line 103 except ValueError, e: ^ SyntaxError: invalid syntax This seems to happen only if --upgrade is used, regardless whether a module was installed before or not. It is easy to circumvent by first uninstalling and then avoiding the option. Should I file an issue? Where? Or submit a patch? cheers - Chris -- Christian Tismer :^) <mailto:tismer@stackless.com> Software Consulting : Have a break! Take a ride on Python's Karl-Liebknecht-Str. 121 : *Starship* http://starship.python.net/ 14482 Potsdam : PGP key -> http://pgp.uni-mainz.de phone +49 173 24 18 776 fax +49 (30) 700143-0023 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

6 8

SandboxViolation: mkdir('/usr/local/virtualenvs/ansible/share', 511) {}
by Guy Rozendorn Jan. 10, 2013

Jan. 10, 2013

Hi, I'm trying to make ansible (https://github.com/Infinidat/ansible) compatible with easy_install (so I can use it later in places that use easy_install and not pip). When I install it with pip, everything works, but not with easy_install: ~/g/i/ansible git:devel ❯❯❯ easy_install -U ansible (env: ansible) ⬆ ✱ ◼ Searching for ansible Reading http://pypi01.infinidat.com/simple/ansible/ Best match: ansible 0.9-develop-30 Downloading http://pypi01.infinidat.com/media/dists/ansible-0.9-develop-30.tar.gz#md5=1… Processing ansible-0.9-develop-30.tar.gz Writing /var/folders/f9/d108d_ds0sz0_qlnzr25_bcr0000gn/T/easy_install-ThM02g/ansible-0.9-develop-30/setup.cfg Running ansible-0.9-develop-30/setup.py -q bdist_egg --dist-dir /var/folders/f9/d108d_ds0sz0_qlnzr25_bcr0000gn/T/easy_install-ThM02g/ansible-0.9-develop-30/egg-dist-tmp-kZvXdB DATA FILES=[('/usr/local/virtualenvs/ansible/share/ansible/', ['./library/add_host', './library/apt', './library/apt_repository', './library/assemble', './library/async_status', './library/async_wrapper', './library/authorized_key', './library/command', './library/copy', './library/cron', './library/debug', './library/easy_install', './library/ec2', './library/facter', './library/fail', './library/fetch', './library/file', './library/fireball', './library/get_url', './library/git', './library/group', './library/group_by', './library/ini_file', './library/lineinfile', './library/mail', './library/mount', './library/mysql_db', './library/mysql_user', './library/nagios', './library/ohai', './library/pause', './library/ping', './library/pip', './library/postgresql_db', './library/postgresql_user', './library/raw', './library/script', './library/seboolean', './library/selinux', './library/service', './library/setup', './library/shell', './library/slurp', './library/subversion', './library/supervisorctl', './library/svr4pkg', './library/template', './library/user', './library/virt', './library/wait_for', './library/yum'])] warning: no files found matching 'packaging/distutils/setup.py' error: Setup script exited with error: SandboxViolation: mkdir('/usr/local/virtualenvs/ansible/share', 511) {} AFAIK, the violation occurs becuase ansible wants to write stuff to /usr/local/virtualenv/ansible, which is out of the sandbox. According to http://docs.python.org/2/distutils/setupscript.html#installing-additional-f…, data files can be outside of the sandbox ('/etc/init.d'), and it looks like this isn't supported by distribute? Any idea would be greatly appreciated. Thanks, Guy

2 1

GLM analysis questions
by Abduljalil Sireis Jan. 9, 2013

Jan. 9, 2013

Dear all, I would like to ask questions about structural solution for GLM analysis of fMRI data. I hope it is not a problem for such long description! :) The subjects of our experiment see two types of video clips. One type is dangerous car accidents and the other is normal car advertisements. We have number of subjects perform this task with one session per subject. Each run consists of 6 clips from each type, the two successive spots are separated by black screen and a yellow cross to fix the subjects eyes. There was not a specific order of the spots but more than two successive ones of the same type were not allowed. All videos were accompanied with voice, so we have visual and audio stimulation. Attached with this email a table of onsets,durations and indices of both conditions. TR (scan repeat time) = 3000 ms. Functional measurement consists of 220 scans. Here is a formulation of the steps needed to be done in the analysis: The GLM analysis that needs to be performed to get the beta estimates is a multiple regression analysis. In other words, I need to specify a model that includes predictors (one predictor for each condition, a confound-mean predictor (all-one vector), and optionally head-motion and trend predictors), and then to fit this model to the data to obtain the beta-estimates. In order to run the GLM, I first need to assemble the model. For this, I can use the list containing the onsets and durations and indices of the stimuli. The next step is to create a predictor for each condition. For each condition, I start off with a vector (220 elements, one for each timepoint) of zeros, then I put ones at those timepoints at which that specific condition was presented. After that, I convolve these predictors with the hemodynamic response function (2-gamma or Boynton) to make the predictors resemble the timing and shape of BOLD measurements. I can add additional predictors to the model, i.e. nuisance predictors that model out effects of motion and slowly-varying trends. I also have to include a confound-mean predictor (i.e. an all-one vector) to model the mean level of brain activation. All predictors together form the model. Since the block durations are not multiples of the TR, it is needed to convolve the hemodynamic response function with the cognitive predictors (one for condition 1, and one for condition 2) at millisecond resolution, and then to subsample the result to get the predicted response at the TR resolution (one measurement each 3 s). * **QUESTIONS** * There is a very unclear thing to me relating to predictors. What should I do exactly in multiplying the HRF with the cognitive predictors? I mean, how the cognitive predictors can be created using the data i have? And also the HRF function. Then what are the steps needed to do the subsample? Better also with the sense of nipype, i have already installed the software but never used it before.

1 0

Re: [Distutils] Some clarifications and/or corrections to PEP 376
by Vinay Sajip Jan. 8, 2013

Jan. 8, 2013

If you move the files, other things can potentially break, too. For example, any scripts installed will have their shebangs adjusted to point to a particular interpreter, e.g. a venv's interpreter. If they get moved to a different location, the shebang lines may become invalid. I don't believe that we have to support such moving of files outside of the knowledge of packaging tools. Regards, Vinay Sajip >________________________________ > From: Kevin Horn <kevin.horn(a)gmail.com> >To: Vinay Sajip <vinay_sajip(a)yahoo.co.uk> >Sent: Monday, 31 December 2012, 19:19 >Subject: Re: [Distutils] Some clarifications and/or corrections to PEP 376 > > >On Mon, Dec 31, 2012 at 12:59 PM, Vinay Sajip <vinay_sajip(a)yahoo.co.uk> wrote: > > >> I agree that PEP 376 isn't ideal in what it specifies in this area. The simplest >>solution would surely be absolute paths only. What are the downsides apart from >>the disk space used for the extra lengths of the filenames? >> >>Regards, >> >>Vinay Sajip >> >> >> > > >If you ever move the files, the absolute paths won't be valid any more. It seems kind of unlikely that this would cause problems, but it might. > >-- >Kevin Horn > >

7 14

Some clarifications and/or corrections to PEP 376
by Paul Moore Jan. 7, 2013

Jan. 7, 2013

I've been looking at the details of PEP 376 (Database of Installed Python Distributions) and there are a couple of aspects that I don't think work properly alongside PEP 370 (Per-user site-packages directory).. 1. The dist-info directory for a distribution is stated as being "located in the site-packages directory". It's not clear how this is intended to work in a PEP 370 world with multiple site-packages. What I propose is that the description be changed to be worded in terms of sysconfig-style locations: the dist-info directory is located in whichever of purelib or platlib is used by the distribution. When the distribution uses both, purelib is preferred, when it uses neither (!) purelib is used. In nearly all cases, this is the same as currently. The exceptions are posix_home (where the directory name isn't "site-packages" but its function is the same), posix_prefix (where purelib and platlib differ, and PEP 376 is currently ambiguous as to which is implied), and any custom schemes that might be created (where PEP 376 is silent, and this proposal has the benefit of at least being specific). I do not believe this changes any actual practice - as far as I have been able to determine any code using dist-info at the moment follows this proposal in the corner cases where it differs from PEP 376. 2. File paths in RECORD are stated as being relative to the "base location" as long as the files sit under that location, or under the "install prefix" where that is above the base location. That's a messy but precise way of saying you can go up a bit as long as you stay within sys.prefix. (Other paths are platform format absolute paths, which is an ugly discrepancy but the only really viable option). Again, this doesn't work as I'd expect it should in a PEP 370 user site-packages. In this case, the answer isn't quite as clear. I would suggest, looking at the schemes defined in sysconfig, allowing any files located in one of the defined sysconfig paths (for the current scheme) to be recorded as relative paths. The paths should be relative to whichever of purelib and platlib was chosen in (1) above. The exception is that where pureXXX and platXXX do not use the same base (posix_prefix and possibly custom schemas) it should not be allowed to have a relative path from a pureXXX to a platXXX or vice versa. That equates to something slightly stricter than the current scheme (although not in a way that's likely to be used in practice), but using the appropriate one of {base} or {userbase} rather than sys.prefix. As noted, the two exceptions are custom schemes (where PEP 376 is silent and would probably end up effectively mandating platform absolute paths throughout) and posix_prefix, where platlib/platinclude/platstdlib are located under {platbase} rather than {base} and the current proposal would probably allow relative paths to be used a little more often that PEP 376 allows. Current practice that I've seen here is not as clear cut, but mostly in the sense that code doesn't consider the corner cases at all, and probably only follows PEP 376 by luck, if at all... Comments would be appreciated. I'm pretty happy that my proposal for (1) is an improvement. With (2) I'm concerned about the posix_prefix case, particularly as I'm a Windows developer and my understanding of Python's layout on POSIX is limited. But I honestly don't think it's possible to do much better than my proposal, and I do think that PEP 376 as it stands now is distinctly worse because it doesn't consider PEP 370 or the posix_prefix case. Also, while these proposals are not 100% backward compatible, I don't believe they change behaviour in the most common scenarios, and given that PEP 376 currently has limited adoption (mainly in distutils2, I believe) I'd suggest that the minor compatibility break now is better than keeping the current system until it's more widely adopted and there are more users to impact. Obviously I'd be looking for views from Tarek and Éric in particular here, as it's their code in distutils2 that would be directly impacted. Paul.

4 10

zc.buildout-1.7.0b2 released
by Jim Fulton Jan. 6, 2013

Jan. 6, 2013

The main goal of the 1.7 release is to provide an update for buildout 1 that won't upgrade itself to buildout 2. zc.buildout-1.7.0b2 fixes a backward-compatibility problem reported in zc.buildout-1.7.0b1. To get the release, download the new buildout 1 bootstrap.py script from http://downloads.buildout.org/1/bootstrap.py: wget http://downloads.buildout.org/1/bootstrap.py and use it to bootstrap your projects. Because this is a non-final release, you need to use the -t option when you run it: python bootstrap.py -t Please try it and let me know if you have any problems. If I don't hear anything, I'll release 1.7.0 final in a week or so. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm

2 6

buildout.dumppickedversions and buildout_versions
by Jim Fulton Jan. 4, 2013

Jan. 4, 2013

On Sat, Dec 15, 2012 at 11:56 AM, Chris Withers <chris(a)simplistix.co.uk> wrote: > On 15/12/2012 09:33, Lele Gaifax wrote: >> >> Alex Clark <aclark(a)aclark.net> writes: >> >>> 19:43 < cullerton> Folks, there's something wonky going on with >>> buildout this morning. When I run bootstrap, it creates a buildout >>> script using buildout 2.0. >>> 0a4. This fails with an error (TypeError: get_dist() takes exactly 4 >>> arguments (3 given)). Changing the version to buildout 1.4.4 seems to >>> fix things. >> >> >> FYI, I just met the same error (using 2.0.0a5), and the culprit was the >> buildout.dumppickedversion extension, that monkey-patches the >> easy_install.py::Installer._get_dist() method (it surprised me at first >> that the error message mentions “get_dist()” but at the referenced line >> in easy_install.py there is a call to “_get_dist()”...). It took a pdb >> session and a “p inspect.getmodule(self._get_dist)” to find out what's >> going on. > > > Yeah, the stuff that buildout.dumppickedversions and buildout_versions > provide should just be in the core. > > Jim, if I worked up a pull request would you merge it? Maybe :) I tried to look at buildout.dumppickedversions and buildout_versions and I couldn't quite tell what they were for or how they were different. Are they different? Or are they 2 versions of the same thing? http://pypi.python.org/pypi/buildout.dumppickedversions gives me a fair idea what it does, but http://pypi.python.org/pypi/buildout-versions looks like almost the same thing and http://packages.python.org/buildout_versions/index.html doesn't state what problem it solves. I realize that a tool to help manage version pins would be helpful. I punted on this when I added the versions feature. Before adding this feature to buildout, I'd like a clearer statement of what problems are being solved and what the approach is. Alternatively, I'd be open to adding an API to make writing an extension possible without depending on internal implementation details. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm

7 14

[ANN] pypiserver 1.0.1 - minimal private pypi server
by Ralf Schmitt Jan. 3, 2013

Jan. 3, 2013

Hi, I've just uploaded pypiserver 1.0.1 to the python package index. pypiserver is a minimal PyPI compatible server. It can be used to serve a set of packages and eggs to easy_install or pip. pypiserver is easy to install (i.e. just 'pip install pypiserver'). It doesn't have any external dependencies. http://pypi.python.org/pypi/pypiserver/ should contain enough information to easily get you started running your own PyPI server in a few minutes. The code is available on github: https://github.com/schmir/pypiserver Changes in version 1.0.1 ------------------------ - make 'pypi-server -Ux' work on windows ('module' object has no attribute 'spawnlp', https://github.com/schmir/pypiserver/issues/26) - use absolute paths in hrefs for root view (https://github.com/schmir/pypiserver/issues/25) - add description of uploads to the documentation - make the test suite work on python 3 - make pypi-server-standalone work with python 2.5 -- Cheers Ralf

1 0

[issue147] "test" command breaks 'atexit' handlers
by Brian Lauber Jan. 3, 2013

Jan. 3, 2013

New submission from Brian Lauber: I wrote a module that registers an "atexit" handler. However, when I executed the unit tests for this module via setuptools, the "atexit" handler would never be invoked: python ./setup.py test The root cause of the issue is that fact that setuptool's "test" command un-loads modules between each test run. This means that the 'atexit' module is unavailable when Python exits, which means that the callbacks are never invoked. It is possible to prevent setuptools from un-loading the 'atexit' module by importing 'atexit' at the beginning of the setup.py file. This allows the 'atexit' handlers to run, but they ultimately fail because all of the modules have already been unloaded. You can find a more complete write-up on the issue here: https://briandamaged.org/blog/?p=1181 ---------- messages: 701 nosy: Brian.Lauber priority: bug status: unread title: "test" command breaks 'atexit' handlers _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue147> _______________________________________________

1 0

zc.buildout-1.7.0b1 released
by Jim Fulton Jan. 2, 2013

Jan. 2, 2013

The main goal of this release is to provide an update for buildout 1 that won't upgrade itself to buildout 2. To get the release, download the new buildout 1 bootstrap.py script from http://downloads.buildout.org/1/bootstap.py: wget http://downloads.buildout.org/1/bootstap.py and use it to bootstrap your projects. Because this is a non-final release, you need to use the -t option when you run it: python bootstrap.py -t Please try it and let me know if you have any problems. If I don't hear anything, I'll release 1.7.0 final in a week or so. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton Jerky is better than bacon! http://zo.pe/Kqm

3 4