Re: [Distutils] setuptools and sdist on Mac OS X, tarfile flukes

[Hanno Schlichting]

Hi,

Phillip J. Eby wrote:
> At 05:38 PM 2/15/2007 +, Sidnei da Silva wrote:
>> Not sure if anyone reported a similar issue here since I'm not subscribed, 
>> but
>> here it goes.
>>
>> Some of the new plone.* eggs are being built on OS X by the developers, they
>> usually do 'setup.py sdist bdist_egg upload'. Sometimes they only do 
>> 'setup.py
>> sdist upload'
>>
>> Turns out that if you try to easy_install and there's only the sdist package,
>> but no egg, easy_install uses tarfile to unpack the package, build an egg and
>> install the egg. However, for some reason some of those nasty '._'
>> files that OS X creates end up in the tarball. And tarfile then fails to 
>> unpack
>> the tarball. One such package is 'plone.app.controlpanel 1.0a2'
>> (http://cheeseshop.python.org/packages/source/p/plone.app.controlpanel/plone.app.controlpanel-1.0a2.tar.gz#md5=2b2afeaba0d067f6b1a6707c6d69311d),
>> with the following traceback:
>> ...
>> I'm left wondering if the issue is:
>>
>>  a) Windows
>>  b) The nasty OS X file
>>  c) The Python 'tarfile' module
>>  d) setuptools
>>  e) None of the above :)
> 
> It appears to be a combination of "a" and "c".  Windows Python 2.5 does not 
> have an issue with the above file, nor does Cygwin Python 2.3.  Windows 
> Python 2.3 and 2.4 do have the problem.
> 
>> Thoughts?
> 
> Dunno.  It sounds like the people making these distributions have an 
> over-eager MANIFEST.in or an over-eager source control system.  They should 
> probably add a MANIFEST.in rule to exclude the files from the source release.

I looked into this a bit more and it seems you cannot fix this issue by
using a MANIFEST.in. The problem is that those resource forks aren't
found as regular files and so in return you cannot exclude them via a
filter.

According to
http://forums.macosxhints.com/archive/index.php/t-43243.html those
resource forks are created by the Mac OS tar program on the fly, which
is used internally by distutils.archive_util.

There is no command line switch to disable this behavior but some brave
soul looked through the source code of the modified tar and found that
setting an environment variable called
'COPY_EXTENDED_ATTRIBUTES_DISABLE' to any value should disable this
behavior.

I just tried to do a 'python setup.py sdist' for plone.app.controlpanel
and a 'tar tzvf plone.app.controlpanel-1.0b3dev-r13784.tar.gz' shows me
a ._setup.py file in there.

If I first do 'export COPY_EXTENDED_ATTRIBUTES_DISABLE=true' and then
rerun the sdist command I don't see the ._setup.py file anymore in the
tarball.

I wonder if this should be fixed on the distutils level? Does including
those resource forks make any sense for source tarballs in some
situation? Or could the archive_util set this environment variable on
Mac OS X prior to calling tar and reset it afterwards?

Hanno

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] [zc.buildout] upgrade with changed explicit recipe version

[Hanno Schlichting]

Hi.

I ran into a problem with zc.buildout while upgrading a customers 
buildout and wondered if the problem I encountered is a general one.

The buildout in question had one recipe pinned down to an exact version 
as in:

[buildout]
parts =
 plone

[plone]
recipe = plone.recipe.plone==3.0.2

To upgrade this environment I changed the explicit version to 3.0.6:

[buildout]
parts =
 plone

[plone]
recipe = plone.recipe.plone==3.0.6

When rerunning the buildout script I got an error during uninstall of 
the plone part. It complained that the plone.recipe.plone recipe version 
3.0.2 was not available.

 From my understanding of this, buildout parses the version requirements 
first and at the point where it wants to uninstall the plone part, only 
the newer 3.0.6 version of the recipe is available.

The workaround was to change .installed.cfg and remove the version 
restriction, so any version of the recipe would be accepted to uninstall 
the part, but I wonder if there is a general problem here or if we are 
misusing the version restrictions?

I have the feeling that buildout should either add the old recipe to the 
environment to satisfy the uninstall requirement or accept newer 
versions of a recipe to uninstall older versions. Thoughts?

Hanno

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [zc.buildout] upgrade with changed explicit recipe version

[Hanno Schlichting]

Hi.

Jim Fulton wrote:
> On Apr 2, 2008, at 3:44 PM, Hanno Schlichting wrote:
> I think there is a general problem and no, you aren't miss-using the  
> the version restriction.
> 
>> I have the feeling that buildout should either add the old recipe to  
>> the
>> environment to satisfy the uninstall requirement
> 
> Unfortunately, there can be only one version in the environment at a  
> time.
> 
>> or accept newer
>> versions of a recipe to uninstall older versions.
> 
> That is probably better.
> 
> Another option might be to uninstall in a separate process. (Just  
> thinking out loud.)
> 
> I haven't seen this situation before, although I should have expected  
> it.
> 
> I'll think about this and respond in a day or 2.  If I forget, bug me,  
> or create a launchpad issue.

There has already been a report in November last year by Wichert: 
https://bugs.launchpad.net/zc.buildout/+bug/163776

I added the information from this conversation to the report.

Hanno

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] zc.buildout 1.1?

[Hanno Schlichting]

Hi buildout-people,

I have noticed us slacking a bit on the proper release management side 
of buildout as of late. It seems we have chosen to use the 1.0.x 
releases for introducing new features which has led to at least one 
completely broken release already.


How do people feel about declaring the 1.0.x line as stable and 
maintenance only and do new feature work in a 1.1 release instead?


Thanks,
Hanno

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Adding alias into Distutils ?

[Hanno Schlichting]

Tarek Ziadé wrote:
> setuptools 'alias' command is very handy
> 
> 
> What about integrating it into Distutils ?

-0 it's not an essential part in any way.

If the feature didn't exist, I would have just created some aliases via
Unix alias command or wrote me a simple shell script. There's some many
other ways to get aliases.

Hanno

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] Should metadata known about compatibility?

[Hanno Schlichting]

Hi,

I'd like to suggest that distutils metadata should gain a way of
specifying compatibility with packages in addition to the requirement of
packages.

What are the use cases?

- A package wants to express that it works with both Python 2 and 3.
- A package wants to express that it works with TurboGears 2 or Plone 4

>From my point of view this information is most useful for framework-like
packages, when those do major backwards incompatible changes to their
code base.

In those circumstances typical question that people want to have answers
to are:

- For a press release of Python or a Framework, how many packages in
PyPi already support the new version?

- Running a particular application consisting of 200 packages, can I
upgrade to the next version of Framework X?

This type of information would always be optional and won't ever be used
for all packages. I think it could be nonetheless helpful in many
circumstances.

On a side note to express this information for Python itself, it would
be a good idea to expose the Python version in a distutils way, so I
could also write:

install_requires=['Python >= 3.0']

Comments?

Hanno

P.S. We want this kind of behavior for Plone, to give "plugins" to the
application / framework the ability to express this information.

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Should metadata known about compatibility?

[Hanno Schlichting]

Tarek Ziadé wrote:
> On Tue, Apr 14, 2009 at 9:27 PM, Hanno Schlichting  
> wrote:
>> Tarek Ziadé wrote:
>>> On Tue, Apr 14, 2009 at 9:07 PM, Hanno Schlichting  
>>> wrote:
>>>>
>>>> I'd like to suggest that distutils metadata should gain a way of
>>>> specifying compatibility with packages in addition to the requirement of
>>>> packages.
> 
> I think the classifiers works pretty well there. (If we look at your use 
> cases,
> and the classifiers browsing features at PyPI)

Right, it seems to be a bit of an abuse to use classifiers which include
version numbers, but it might work well enough.

What I care most about is to have a defined way of stating this
information, so we can build tools on top of it.

I'd like to have Plone get the ability to get a button saying "Check for
upgrade" which can produce a version list of locally installed packages,
post them to a service at plone.org and get back a result saying:
"There's a new version of Plone out, but 3 of your 9 installed plug-ins
are not yet available for this version."

> The only problem I can see is the fact that they have to be added "manually"
> at PyPI.  If we put apart this problem, do you see any remaining problem ?

Yes, but this might just as well be solved by documenting the procedure
for requesting new classifiers clearly.

Hanno

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] mirror plone buildout

[Hanno Schlichting]

Mihamina Rakotomandimby (R12y) wrote:
> I would like to first download the Plone (+deps) locally, with a dedicated
> FTP client, that can handle more or less correctly the stalls.
> 
> Have you got some related documentation somewhere in your bookmarks?

Plone offers buildout based installers for all platforms. Look at
http://plone.org/products/plone/releases/3.2.2 to get the most recent
stable release. You download one file which includes all dependencies in it.

Hanno

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] RFC : PEP 376 - egg.info

[Hanno Schlichting]

Tarek Ziadé wrote:
> On Mon, May 4, 2009 at 6:12 PM, Floris Bruynooghe
>  wrote:
> 
> Ok then, we will have to provide extra documentation to make people
> understand that the '.egg-info' directory has absolutely nothing to do
> with egg-the-format
> but is rather a metadata container.

> So removing the 'egg' part of 'egg-info' seemed natural to me at this point.

That seems reasonable to me. Just name it something a little more
verbose, like pkg-info or metadata or whatever it actually is that it
contains.

And since this is such a wonderful bikeshed opportunity, I'd suggest you
just pick whatever concept-neutral name you personally like the best ;)

Hanno

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Adding entry points into Distutils ?

[Hanno Schlichting]

Doug Hellmann wrote:
> On May 6, 2009, at 1:46 PM, P.J. Eby wrote:
> 
>> At 10:59 AM 5/6/2009 -0400, Doug Hellmann wrote:
>>
>>> On May 5, 2009, at 10:50 PM, P.J. Eby wrote:
>>>
 At 12:03 PM 5/6/2009 +1000, Ben Finney wrote:
> I don't see any advantage, in the context of this discussion, to
> having an additional, incompatible naming for full-path-to-a-class.

 Setuptools doesn't limit an entry point to being a class, function,
 or other top-level name within a module.  It can be a method of a
 class, or an attribute of an attribute.  The ':' removes any
 ambiguity as to which part of the name is the module, and which
 parts are attributes within that module.
>>>
>>> Is that level of complexity useful in practice?  I can understand how
>>> it came to be implemented, but is it actually used by any projects?
>>
>> I use it; I'm not sure who else does.
>>
>> The particular use case I have (and that's most likely to be shared)
>> is that the calling app or framework wants a callable or function, but
>> the providing app or library implements that callable as a classmethod
>> for convenience.
> 
> That's pretty much what I expected.  It feels a little messy to have
> plugins exposing "internals" like that but not so much so that I propose
> we don't allow it. The ":" syntax seems like the right way to go.

I'd be tempted to call this an edge-case. You should be able to expose
the internal detail you'd need via a module scope alias for the
particular case. That seems easier than providing a whole new notion.

Hanno

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Adding entry points into Distutils ?

[Hanno Schlichting]

Ian Bicking wrote:
> On Wed, May 6, 2009 at 1:32 PM, Tres Seaver  > wrote:
> 
> I'm actually a big fan of the ':', because it makes explicit the
> difference between the "import" and the "named thing", even for
> module-scoped names.
> 
> Yeah, I also like it primarily for clarity.  Also you can provide better
> error messages when it fails, matching up the error against the intention.

[...]

> Also I don't
> think there's any strong precedence for purely dot notation, loading
> objects from strings is something that's always done ad hoc, and the
> only widely used library I know of that people use for this is
> Setuptools (indirectly through entry points).

The one I and others use in quite many places is zope.dottedname [1]
(the actual function is at [2]). This one doesn't make any difference
between modules and attributes. It has no zope dependency but happens to
be used throughout the entire Zope / Plone stack.

Hanno

[1] http://pypi.python.org/pypi/zope.dottedname
[2]
http://svn.zope.org/zope.dottedname/trunk/src/zope/dottedname/resolve.py?view=markup

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Eggs, zc.buildout, and Distributed Version Control, oh my!

[Hanno Schlichting]

Ross Patterson wrote:
> and of course the elephant in the living room, svn:externals.  :)

> Even with that, however, I still find the lack of a good "what changes
> have I made to all sub projects" overview to be rather painful.  Maybe
> this is outside the scope of the individual DVC tool and should be
> handled by an independent tool that aggregates status across projects.
> How do others handle this kind of situation?

Both the official Plone development and we at Jarn internally moved to
http://pypi.python.org/pypi/mr.developer for this use-case.

It has a among others a VCS agnostic "./bin/develop status" command and
gets rid of svn:externals in favor of managing them inside the buildout
configuration.

Hanno

___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Announcing the 'Distribute' project

[Hanno Schlichting]

Hi.

On Thu, Jul 16, 2009 at 2:13 AM, Tarek Ziadé wrote:
> We have started a new project called 'Distribute'. It's a fork of
> setuptools and its initial purpose will be to tackle
> the most annoying bugs found in setuptools 0.6c9 version.

I have fixed the Subversion 1.6 incompatibility as a first bug in the
"most annoying" category. See
http://bitbucket.org/tarek/distribute/issue/1/ for the bug report.

The excellent refactoring found in the original issue in the
setuptools bug tracker isn't applied yet. I'll do that including the
more thorough testing required for the larger change after we have
released our first 0.6 final release.

I'll go through the setuptools tracker to see if there are more very
simple bug fixes than can be made. If you know of a particular typo,
SyntaxError or any other non-controversial two-line change, feel free
to point me to them.

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] Progress on the first distribute release

[Hanno Schlichting]

Hi there.

As promised I have gone through the setuptools tracker and tried to
identify the easy and ready-to-apply patches. As a result I have
applied the patches found in eight tickets [1] to the current
distribute code.

If you have another issue that is similarly uncontroversial and like
it to be fixed, please report a new issue at
http://bitbucket.org/tarek/distribute/issues/new.

I've readied my Windows box to build the required binary distributions
and installers for the 0.6 release. So hopefully there's just a few
more documentation updates to make, before we can get this release
out.

Cheers,
Hanno

[1] In all its gory details these issues were:

* Protected against failures in tarfile extraction. This closes
http://bitbucket.org/tarek/distribute/issue/10.

* Allow find_on_path on systems with tight permissions to fail
gracefully. This closes http://bitbucket.org/tarek/distribute/issue/9.

* Corrected inconsistency between documentation and code of add_entry.
This closes http://bitbucket.org/tarek/distribute/issue/8.

* Made api_tests.txt doctest compatible with Jython. This closes
http://bitbucket.org/tarek/distribute/issue/7.

* sandbox.py replaced builtin type file with builtin function open.
This closes http://bitbucket.org/tarek/distribute/issue/6.

* Immediately close all file handles. This closes
http://bitbucket.org/tarek/distribute/issue/3.

* Backported old distutils behaviour for add_defaults, to avoid a
recursive loop when setuptools builds the file list. This closes
http://bitbucket.org/tarek/distribute/issue/2.

* Added compatibility with Subversion 1.6. This references
http://bitbucket.org/tarek/distribute/issue/1.
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Progress on the first distribute release

[Hanno Schlichting]

Hi.

On Fri, Jul 17, 2009 at 2:07 AM, David Lyon wrote:
> If I find anymore issues I can post them to there instead of the
> mailing list.

Our bug tracker is open for submission by anyone. It's not a magical
thing though. So the same rules about good bug reports, repeatable
steps, preferably patches with tests and so on apply. Meta questions
and general observations about controversial issues are as likely to
get a non-optimal treatment as everywhere else ;)

> Somebody should update the easy_install web site to direct users
> to post to the tracker and not to the mailing list.

We'll update the documentation soon. We will need to find a new place
to put the documentation for this fork, though.

> People are happy using Trackers and I'm starting to notice that
> bug reports posted to the distutils mailing list are probably
> being ignored at best.
>
> Being ignored in a tracker is an entirely different thing - haha

Bug reports are ignored or never followed up upon on every mailing
list I've seen. There's a reason why bug trackers exist ;)

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Progress on the first distribute release

[Hanno Schlichting]

On Fri, Jul 17, 2009 at 11:54 AM, Tarek Ziadé wrote:
> On Fri, Jul 17, 2009 at 11:50 AM, Hanno Schlichting wrote:
>> We'll update the documentation soon. We will need to find a new place
>> to put the documentation for this fork, though.
>
> Let's create a Sphinx-based website. I can host it on my server. As
> soon as the name is chosen, we can set a domain
> name too.
>
> We can start to build the sphinx-based doc in the docs/ directory.

+1.

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [Distribute] What versions should we support?

[Hanno Schlichting]

On Fri, Jul 17, 2009 at 11:51 AM, Lennart Regebro wrote:
> 2009/7/17 Tarek Ziadé :
>> When Python 2.7/3.2 are out, I am planning to release a standalone
>> version of Distutils that will work starting at 2.5.
>> Which means that the 0.7 series of Distribute will be able to work with it.
>>
>> From there we can maintain a 0.6.x maintenance branch that will work
>> with vanilla Python from 2.4 to 2.6 + 3.1

Yes. The current setuptools 0.6c9 release claims to be compatible with
Python 2.3 to 2.6. I'd like to maintain that same promise for the 0.6
release series. I don't see Python 3.x support as mandatory for these
maintenance releases. It's a new feature which can go into a new major
release. It's likely to be somewhat disruptive to do while retaining
support for all older releases.

>> and a 0.7.x branch that will work with Python 2.7/3.2 and 2.5/2.6/3.1
>> if the users install the Distutils backport.
>
> Sounds reasonable.

+1

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [Distribute] What versions should we support?

[Hanno Schlichting]

On Thu, Jul 16, 2009 at 10:57 PM, Lennart Regebro wrote:
> The current trunk (or whatever mercurial calls it) doesn't work with
> 2.4, because of a try/except/finally clause. That's fixable, but I
> ain't gonna fix it if we don't want to support 2.4 any more. I would
> claim that we should support 2.4.

Where exactly do you see that try/except/finally? I cannot find such a
construct in the code I'm looking at.

I'm on "hg clone ssh://h...@bitbucket.org/tarek/distribute distribute"
and there's no branches yet as far as I know.

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [Distribute] What versions should we support?

[Hanno Schlichting]

On Fri, Jul 17, 2009 at 2:46 PM, Tarek Ziadé wrote:
> The current status of 2.5/2.6 support is unclear to me in Plone land
> for instance,
> I thaught it was effective.

The story for most of Plone and Zope 2 / Zope Toolkit is:

- Stable released versions of Plone and Zope 2 only work with Python
2.4 - nothing newer.
- The last Zope 3 release also works with Python 2.5.

By the end of this year we will have new major versions of all of
them, which do longer support Python 2.4 but instead need Python 2.5
or 2.6. They officially recommend 2.6.

Considering adoption rate of new releases, that means there's still
going to be a number of years where Python 2.4 is going to be dominant
in the Zope/Plone world. But then again there's still many Python 2.1
and Python 2.3 installations out there.

That calls for the willingness to support a backwards compatible 0.6
release series, but no features or improvements need to be made to
this line. In the end current setuptools and buildout works for all
Plone and Zope users the way it is. The Subversion 1.6 bug is the only
major one I encountered which hit people constantly.

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Progress on the first distribute release

[Hanno Schlichting]

Hi.

Following up on myself :)

We started to work on the documentation, added the basic Sphinx
infrastructure and added a new combined changelog which lists the
changes made in this fork.

Since we have forked the setuptools 0.6 branch, I have carefully
reviewed what changesets we missed from the setuptools trunk. Based on
this review I have merged a couple more bug-fixes and style changes to
our code. There are only a minor number of remaining differences to
the setuptools trunk, which are not appropriate for a maintenance
release. These are tracked at
http://bitbucket.org/tarek/distribute/issue/14.

In addition to the eight issues we have fixed so far, these are the
new additions we applied, solely based on the work from the original
contributers:

* Packages required at build time where not fully present at install
time. This closes http://bitbucket.org/tarek/distribute/issue/12.

* Avoid a call to /usr/bin/sw_vers on OSX and use the official
platform API instead. Based on a patch from ronaldoussoren. This
closes http://bitbucket.org/tarek/distribute/issue/5.

* Fixed a SandboxViolation for mkdir that could occur in certain
cases. This closes http://bitbucket.org/tarek/distribute/issue/13.

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] Distribute - issue tracker

[Hanno Schlichting]

Hi there.

In order to not disrupt the setuptools project in any way, we have
chosen to have our own issue tracker at
http://bitbucket.org/tarek/distribute/issues and mirror issues
instead. We felt that comments like "this is fixed in Distribute -
come join us" are inappropriate to leave in the setuptools tracker ;-)

Obviously this leaves us with a synchronization problem. We already do
have a new issue and comments on issues which are unique in our own
tracker. For now I've used a stupid low-tech approach and manually
created a Wiki page at
http://bitbucket.org/tarek/distribute/wiki/bug_listing which lists our
own issues and their relations to the setuptools issue tracker. This
is of course in addition to a comment on each issue explaining its
origin.

If someone has a better idea on how to synchronize these trackers or
can provide insight in proven techniques for forks in this way, please
speak up. Otherwise I'm going to continue to manually mirror all
issues over from the setuptools tracker into our own.

Cheers,
Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Colour this bikeshed: Name for setuptools fork

[Hanno Schlichting]

Hi.

On Fri, Jul 17, 2009 at 7:48 PM, P.J. Eby wrote:
> Eh?  I encourage the fork.  I only don't want it called setuptools.  Call it
> the People's Republic of Setuptools or something.  ;-)

Thank you!

Judging by the current vote outcome and the interest of the people
actually doing the work on this right now, I think we'll call it
Distribute - driven by the Fellowship of the Packaging. There needs to
be some silliness involved ;-)

> As I said, at least half the patches I get are good.  Knowing *which* half
> is the part that has tougher qualifications.  ;-)

Sure. Bug management that only consists of applying well tested and
thought out patches wouldn't be any fun. I made my choices of which
bugs and patches to accept, as seen from my progress report. Obviously
I left out all the hard ones for now.

> I don't intend to spend a lot of time on that for the fork, actually, at
> least not on an unsolicited basis.

I hope we will be able to get some more productive and constructive
discussions than the usual heated debates we see on this list. It's
good to know that you are in principe willing to share your expertise
with us.

Thanks,
Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Colour this bikeshed: Name for setuptools fork

[Hanno Schlichting]

On Fri, Jul 17, 2009 at 6:48 PM, Leonardo Santagada wrote:
> Setuptools is dead, but the fork should be named something else just to show that development doesn't have anything to do with the way setuptools and is in fact a new and live project. People that were burned by setuptools should give distribute a new chance.

As with every OS project our fork will need to better define what
exactly it wants to achieve.

I will just say that I wholeheartedly disagree with the underlying
notion of the above statement.

I think setuptools is by and large a huge success and has pushed
package management in Python to a new level.  What we need is ongoing
maintenance and very careful evolution of it. Package management is no
place to go crazy and fancy. We will need to carefully look at what we
want to do and how we do it after some of the early strong emotional
reactions have settled down.

Anyone who wants to rewrite setuptools from scratch or thinks
"easy_install must die" probably will be very disappointed by the
distribute fork.

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [distribute] Python 3 support checked in, and fucked everything up.

[Hanno Schlichting]

On Fri, Jul 17, 2009 at 11:18 PM, Lennart Regebro wrote:
> I checked in the Python 3 support, which for some reason made the new
> python3 branch the main active branch. Which of course wasn't the
> intention. Also, an earlier name of the branch got added. I want that
> removed.

Thanks for the Python 3 support work.

I've cleaned up your commits a bit. The "regebro-python3" branch is
now marked as closed and merged into the "python3" branch. I've also
made a new commit on the setuptools-0.6 branch to create a proper
second head again. We are back at two active branches and
corresponding heads as shown at
http://bitbucket.org/tarek/distribute/changesets/.

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [distribute] Python 3 support checked in, and fucked everything up.

[Hanno Schlichting]

On Sat, Jul 18, 2009 at 9:01 AM, Lennart Regebro wrote:
> The best path forward right now seems to me to completely delete the
> branches, including from history, which is possible in Mercurial,
> assuming everybody recreated their clones afterwards, apparently.

I don't see the problem. Note that branches in Mercurial are quite
different from branches in SVN. Also typical SVN-style use might not
be appropriate for Mercurial. I'm myself using this only for a very
short time, so I'm in no position to lecture people about anything
here.

But looking at http://bitbucket.org/tarek/distribute/changesets/ all
looks fine to me. I gave the setuptools-0.6 branch the name default
now, which seems to cause it to be the "default" you get as a working
copy when cloning the repo.

Doing "hg branches --active" shows me two active branches, default and
python3. You can switch to the python3 one using "hg up -C python3".

What exactly the best practice on reintegrating changes from one
branch to another is, I haven't quite figured out yet.

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Colour this bikeshed: Name for setuptools fork

[Hanno Schlichting]

On Sat, Jul 18, 2009 at 2:05 AM, P.J. Eby wrote:
> (Btw, I'm not sure if you really want to drop entry-points.txt from revision
> control, since ISTM a fresh checkout will not be able to run egg_info and
> rebuild it, unless you also add a hack to Distribution.get_command_class()
> so it (and any other setuptools commands it relies upon) can be found.  If
> it seems to be working as-is, my guess is it's because an
> already-elsewhere-installed setuptools version on sys.path is providing the
> glue by way of *its* entry-points.txt.  Try it and see!)

Ah thanks, I could reproduce the problem indeed and put the
entry_points.txt back into version control.

I build all my different Python versions based on a zc.buildout, so
obviously setuptools is installed globally in those, which makes them
quite bad for working on setuptools itself. Luckily I have those
system installed bad Python versions on the Mac, which I never touched
:)

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [distribute] Python 3 support checked in, and fucked everything up.

[Hanno Schlichting]

On Sat, Jul 18, 2009 at 1:08 PM, Georg Brandl wrote:
> Lennart Regebro schrieb:
>> 2009/7/18 Hanno Schlichting :
>> OK, that solved that problem. It's annoying that you can't delete
>> branches so they won't show up. OK, you can inactivate them, but the
>> default is to list all, and you have to type --active to not list the
>> inactive ones. That's just daft. It means that if you make a mistake,
>> like I did, you have to basically live with that mistake, and you
>> can't prune old branches in any reasonable way.

Lennart, if you don't like the default then just add the following to
your hgrc file:

[defaults]
branches = --active

Mercurial just got the explicit notion of "closing" branches in
version 1.2, which seems to be made exactly for this use-case. You
want to see less clutter in the branches list.

> I'm sure that this discussion will be welcome on the mercurial mailing list.
> Maybe they haven't given their branches as much thought as you have.

From what I can tell, using named branches seems to be considered
advanced and unusual in Mercurial. There's no need to give different
heads names at all and using entirely different clones seems more
usual. It's just those pesky SVN converts, which are so used to using
branches.

>> Anyway. I found that with the mqextension strip you seem to be able to
>> delete branches.
>> I'd be happy to delete all my changes this way, and start over, this
>> seems doable. (It's not much work).
>> But before I do this, I would like confirmation that I should do this.
>> I think it's a good idea. The python3 branch is broken now anyway.
>
> Note that you cannot push "stripped" changesets.  strip destructively alters
> the history, and while that's a good thing as long as you only do it locally,
> it would have detrimental effects on other clones, which e.g. could have
> new changesets based on those you stripped.  So once you pushed a changeset,
> and you really want to get rid of it, you must tell everyone who has a clone
> to do the strip as well (starting with Jesper at bitbucket), or risk getting
> contributions that reintroduce these changesets.

Yes. Please don't try to strip anything. Just because you seem to be
able to do this, doesn't make this a good idea.

How often did you manually alter SVN repositories to erase some part
of their history? It's for the rare case where highly confidential
information leaked or otherwise extreme cases - not for beautifying
the log. Learn to live with your mistakes ;-)

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [Distribute] project status

[Hanno Schlichting]

2009/7/18 P.J. Eby :
> Btw, does this changeset:
>
>   http://bitbucket.org/tarek/distribute/changeset/52bb77ad5030/
>
> Work on Python 2.3 on the Mac?  platform.mac_ver() was not documented until
> 2.4; was it actually introduced in 2.3?

In my build of Python 2.3 the function is available. It's also visible
in the source tree for easy reference:

http://svn.python.org/view/python/branches/release23-maint/Lib/platform.py?view=markup

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Colour this bikeshed: Name for setuptools fork

[Hanno Schlichting]

On Sat, Jul 18, 2009 at 9:50 PM, P.J. Eby wrote:
> Also, this entire discussion may be moot if, as I'm currently understanding
> it, this is simply a matter of other people doing maintenance and bug fixes
> to the 0.6 branch...  in which case there is a very strong possibility that
> I'll just bless various versions of it as official 0.6 versions of
> setuptools.
>
> (One obstacle to this actually happening, though, is the part where they're
> stripping out my release tools, like wikiup.cfg, version+version.dat, etc.,
> as I would need to add these back in order to actually do a release.)

In order to make it easier for you to bless things, I created a branch
of our work, which very closely resembles the official setuptools 0.6
branch, including the correct distribution name and including all your
build and release tools.

It's a "hg up -C setuptools-compatible-0.6" away after cloning the
repo. It does need some more tweaks to version identifiers (is it 0.6
or 0.6.0 or 0.6-final ...) and lacks the md5 checksums for release
files, since these are obviously not produced yet.

I'd be happy to produce the Windows binary installers for an official release.

I'm sure we do have some disagreements about how to evolve setuptools
after the 0.6 branch. But our ideas of what is appropriate for
maintenance releases seem to match quite well.

Cheers,
Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [Distribute] Python 3 porting effort - plans proposal for 0.7/0.8

[Hanno Schlichting]

On Thu, Jul 23, 2009 at 8:56 PM, Lennart Regebro wrote:
>> But It's quite important imho to have the best strategy for next
>> releases, and I can't picture the same branch with bits of 2.x and 3.x 
>> syntax in it.
>
> You don't have that. You write for Python 2, and convert it with 2to3.

+1, that's the official way and we should stick to that.

And at some point we hopefully get the 3to2 tool and can switch the
process around with the 3.x code being the canonical one.

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] idea for Distribute: make unzipped eggs be the default

[Hanno Schlichting]

On Tue, Jul 28, 2009 at 4:23 PM, Zooko Wilcox-O'Hearn wrote:
> http://bugs.python.org/setuptools/issue33 # zipped eggs cause various
> problems -- perhaps set default setting to unzipped?

+1

> Perhaps the Distribute project should consider installing eggs unzipped by
> default.  It would avoid a slew of problems (see that ticket for a catalog
> of problems), would be fully backwards compatible (it is what many people
> already do, per the suggested workaround, and I've never heard a report of a
> problem due to an *unzipped* egg), and I think it might improve performance
> a bit.  (Yes, that's right -- we haven't done a real measurement of
> performance, but the few times that people briefly glanced at performance it
> seemed like zipping the eggs made them slower to load, not faster.)

The measurements I know of suggest that having lots of zipped eggs for
each package doesn't provide any benefit whatsoever and is usually
worse than normal unzipped eggs.

Only if you combine a whole lot of packages and code into one giant
manually crafted egg, you sometimes get benefits from it. But that's a
specific deployment optimization that should be left to specific
situations.

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Distribute and zc.buildout + bootstraping file names + release/branches roadmap

[Hanno Schlichting]

On Wed, Aug 5, 2009 at 9:46 PM, Tarek Ziadé wrote:
> I'll wait for any other feedback and for Hanno feedback (they are
> sprinting in Bristol/UK)
> and I'll push a release Thirsday or Friday unless some bad feedback occurs.

I had some problems, which were all due to the fact that I had various
"unofficial" setuptools installations all over the place claiming to
be newer setuptools versions, like
http://dist.jarn.com/public/setuptools-0.6c9-1.zip. I just removed all
traces of setuptools from my various site-packages and buildout egg
caches and bootstrapped everything again. After that it worked fine.

I also changed a couple of references of ez_setup with pointers to
bootstrapping in the code. bootstrapping was suggesting to me to
upgrade to a newer version by running ez_setup, which would obviously
be a bad idea ;)

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Splitting distribute in several distributions

[Hanno Schlichting]

On Wed, Aug 12, 2009 at 2:18 PM, Barry Warsaw wrote:
> On Aug 12, 2009, at 4:35 AM, Tarek Ziadé wrote:
>
> One feature I would love to see make standard is the ability to import a
> package and check its __version__.  Version information must be available
> from Python, and it seems like __version__ is the standard place to put it.
> Too many times I've had to figure out the version of foo.bar that I'm
> using.  When I can do
>
 import foo.bar
 foo.bar.__version__
> 3.2.1
>
> I am a much happier camper.

The easiest way I could find right now seems to be:

>>> import pkg_resources
>>> dist = pkg_resources.get_distribution('foo')
>>> dist.version
3.2.1

Which isn't too bad and could be simplified into an even simpler API call.

If the package author doesn't set a __version__ attribute in his own
code, I'd be hesitant to magically make it available from the
accompanying metadata. If it's part of the metadata, an explicit API
that makes it clear that you are querying the package metadata seems
cleaner to me.

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Static metadata using setup.cfg

[Hanno Schlichting]

On Mon, Aug 17, 2009 at 9:34 AM, Tarek Ziadé wrote:
> Following the discussion on the format of the static metadata file,
> it's evident for me that it has to be a ConfigParser file.

Big +1

> I am proposing the current scheme (applying it in this precise order):
>
> 1/ if the value contains '\n' signs, it's a  list and values are
> splitted using \n, then each element is left stripped
>   (not sure yet if we want to right strip them too)
>
> 2/ if the value contains ',' signs, it's a list and values are
> splitted using ','    (not sure yet if we want to strip them)
> 3/ else, it's a value

I'd generally prefer a full strip() on list entries. People tend to
put trailing whitespace into files without noticing it too much. The
number of whitespace fanatics is certainly larger in Python cycles,
but not among casual developers.

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [buildout] zc.recipe.cmmi and Windows

[Hanno Schlichting]

On Wed, Sep 2, 2009 at 7:36 PM, Jim Fulton wrote:
> I can imagine some  hardy soul trying to make it work on windows,
> possibly untested.  Somebody made zdaemon work on windows, I think. :)

I doubt zdaemon works on Windows. I once made all the Zope2 zopectl
scripts work on Windows. But that was by avoiding zdaemon and
transparently using actual Windows services for start/stop/restart
commands instead.

On the matter of cmmi, I think with enough tools of the MingW project
installed you could make things work. But I wouldn't particularly
trust the stability of things compiled this way. At least not from my
past sysadmin perspective on long term maintenance ;)

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Distribute 0.6.1 released

[Hanno Schlichting]

On Wed, Sep 9, 2009 at 4:45 PM, Neal Becker wrote:
> Is there some summary of advantages of distribute compared to setuptools?

The changelog entries as found at
http://pypi.python.org/pypi/distribute#changes should be a good start.

The Distribute 0.6 series is essentially setuptools with more bugs fixed.

One process related advantage distribute has over setuptools is, that
you can actually contribute patches and code to the project and get
those released after a reasonable time. We welcome contributors to the
project :-)

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Buildout + namespace packages + Django management commands?

[Hanno Schlichting]

On Sat, Sep 19, 2009 at 2:48 PM, Kyle MacFarlane
 wrote:
> The way setuptools (and thus buildout) does namespace packages doesn't work
> with how Django looks for management commands. Django only looks in the
> first package in the namespace on the system path and ignores the rest.

[...]

> So what is the proper way to do this? Django people are saying don't use
> setuptools but everything seems to rely on setuptools.

Namespace packages are a feature of setuptools [1]. If you don't want
to use setuptools, you cannot use namespace packages. You have to
choose either or.

I'd try to convince the Django folks to make their "management console
lookup" pluggable in some way, so you could implement a
setuptools-aware lookup and use it instead.

Hanno

[1] http://peak.telecommunity.com/DevCenter/setuptools#namespace-packages
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Packaging Distribute

[Hanno Schlichting]

On Sun, Oct 4, 2009 at 5:10 PM, Akira Kitada  wrote:
> I'm planning to make a port for Distribute to make it more accessible to 
> users.

That's very much appreciated :)

> For Distribute, there would be a few options to work around this:
>
> 1) Make 0.6 and 0.7 different package, like Distribute and Distribute2
> (Jinja like solution)
> 2) Make 0.7 fat package, which includes 0.6(setuptools compat)
> features as deprecated.
> *) YOUR IDEAS COME HERE.

I would just release the current 0.6 code as a port called distribute for now.

We don't know yet when the 0.7 version is actually going to arrive.
How exactly it looks like might very well change during the next
months. So let's figure out how to deal with 0.7 once it is actually
anywhere near.

In general I would assume each package management system to either
have support for multi-version support or have a standard way to deal
with new feature releases. It's pretty common for any code to give up
backwards compatibility to some degree over time. Distribute is no
different here.

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Package install failures in 2.6.3 - setuptools vs Distribute

[Hanno Schlichting]

On Mon, Oct 5, 2009 at 1:33 PM, Ned Deily  wrote:
> I've opened an issue of the main Python issue tracker outlining the
> problem, primarily for the benefit of affected users who search the
> tracker:
>
>   http://bugs.python.org/issue7064

If I understand the comments on this ticket correctly, Tarek has
changed distutils in a way so the last setuptools release continues to
work, correct?

So based on the current state of Python 2.6.4 will work again with an
unmodified setuptools 0.6c9?

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Package install failures in 2.6.3 - setuptools vs Distribute

[Hanno Schlichting]

On Mon, Oct 5, 2009 at 8:38 PM, P.J. Eby  wrote:
> At 07:53 PM 10/5/2009 +0200, Hanno Schlichting wrote:
>>
>> If I understand the comments on this ticket correctly, Tarek has changed
>> distutils in a way so the last setuptools release continues to work,
>> correct?
>
> Yes.  And a very nice fix, done quite quickly.  Thank you Tarek.

Wonderful. This seems to be the right approach to the current problem
for me. Thank you Tarek indeed!

>> So based on the current state of Python 2.6.4 will work again with an
>> unmodified setuptools 0.6c9?
>
> AFAICT, that is correct.

Good. So we can hopefully end this thread and move on to something
more productive.

If anyone wants to step up and provide help in testing pre-releases of
Python, so we can avoid similar situation in the future, that would be
most welcome.

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Package install failures in 2.6.3 - setuptools vs Distribute

[Hanno Schlichting]

On Tue, Oct 6, 2009 at 7:00 PM, Bill Janssen  wrote:
> For me, it's more a matter of "OS X 10.6 already comes with setuptools;
> how can I mitigate the impact of this buggy unmaintained package on the
> systems I'm building to deploy on OS X?".  Adding distribute to the mix,
> however good it is, doesn't help; I'm going to use a pure distutils
> solution.  And I can't really install a bugfix release for the Python
> frameworks in /System; only Apple can do that.

I fear the canonical answer to this problem is: Don't use the system
Python on Mac OS.

It's not particular satisfactory, but as you noticed nobody besides
Apple can fix problems in this Python install or update it to newer
versions. Apple started to include quite a number of projects, like
dateutil, Twisted, NumPy, zope.interface and setuptools to name a few.
They will probably update those the next time in Mac OS 10.7 in one or
two years. Even today the packages they ship are already outdated and
miss bug fixes.

So if you want to deploy to Mac OS, I fear the answer is to encourage
people to install a good pristine Python version instead. Be that the
official GUI installer, Macports, Fink or building your own Python
from source. The installers for the Plone application include a full
Python build for that reason.

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] why would you ever need to specify setuptools as a dependency?

[Hanno Schlichting]

On Fri, Oct 9, 2009 at 1:07 PM, Chris Withers  wrote:
> Reinout van Rees wrote:
>>
>> - Do my libraries have to list a dependency on distribute or on
>> setuptools?
>>  Everything zopish has a 'setuptools >= 0.6c9' in it.
>
> They shouldn't, unless you only require setuptools after your package is
> installed and don't use it in your setup.py, which seems unlikely.
>
> If you need it in your setup.py, what's the point of specifying it? You
> would have had to use it by the time you specify the requirement!

I assume most packages Reinout uses (like all zope.* packages) use
namespace packages. So they actually do depend during runtime on the
pkg_resources module, which happens to be available from either the
distribute  or setuptools distribution. So one of them should be
specified in install_requires.

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] PyPM

[Hanno Schlichting]

On Fri, Oct 9, 2009 at 1:03 PM, Chris Withers  wrote:
> Sridhar Ratnakumar wrote:
>>
>> This release includes a new packaging tool by activestate called Python
>> Package Manager (PyPM).
>
> Is PyPM available separately?

I had been asked for pre-release feedback on PyPM and suggested to
work on the UCS2/UCS4 build problem in PyPM. As a result the following
has been noted (http://workspace.activestate.com/sridharr/pypm/ticket/83):

"Jan further commented that we should not be bothering to make PyPM
work with custom builds of Python other than ActivePython (which is
UCS2 on all platforms) as PyPM is legally supposed to be used only
with ActivePython.

I originally noted the same .. but later thought about users hosting
custom repositories and using custom Python versions (/usr/bin/python
on Ubuntu, for instance). But if they are not legally allowed to use
anything other ActivePython, why bother?"

Which should answer your question about "available separately".

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] why would you ever need to specify setuptools as a dependency?

[Hanno Schlichting]

On Fri, Oct 9, 2009 at 3:14 PM, Jim Fulton  wrote:
> On Fri, Oct 9, 2009 at 7:57 AM, Hanno Schlichting  wrote:
>> On Fri, Oct 9, 2009 at 1:07 PM, Chris Withers  wrote:
>> I assume most packages Reinout uses (like all zope.* packages) use
>> namespace packages. So they actually do depend during runtime on the
>> pkg_resources module, which happens to be available from either the
>> distribute  or setuptools distribution. So one of them should be
>> specified in install_requires.
>
> This functionality should be factored out and merged with pkgutil in
> the standard library.

Sure. That's what http://www.python.org/dev/peps/pep-0382 is about.

But both Python 2.7 and 3.2 are a bit into the future, so it doesn't
help with the current question.

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] distribute or Distribute

[Hanno Schlichting]

On Mon, Oct 12, 2009 at 9:34 AM, Reinout van Rees  wrote:
> I'm probably overlooking it somewhere in the documentation: should I specify a
> distribute dependency as "distribute" or "Distribute"?
>
> I'm used to lowercase so that's what I'm using till now, but I've spotted a
> Capital Letter somewhere...  So which one is preferred?

Please use all lowercase.

I think we referred to the the distribution with a capital D in the
beginning, but decided it's easier to make it all lowercase in the
end.

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] the virtualenv-distribute mess

[Hanno Schlichting]

Hi.

On Mon, Oct 12, 2009 at 9:10 AM, Reinout van Rees  wrote:
> - When using buildout, I get lots of warnings.  The 1.4.2 isn't out yet, but I
>  also won't update all old projects' pinned zc.buildout version so I'm stuck
>  with warnings for a time.

Note that buildout is only really supported with the distribute 0.6.4
release and needs the latest bootstrap from
http://nightly.ziade.org/bootstrap.py. We fixed a variety of issues
with buildout over the weekend. It seems to work with zc.buildout
1.4.1 now, though.

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] why would you ever need to specify setuptools as a dependency?

[Hanno Schlichting]

On Tue, Oct 13, 2009 at 7:31 PM, Tres Seaver  wrote:
> Why?  Nobody will check / enforce / understand what 'install_requires'
> even means except setuptools / distribute.

To quote Toshio Kuratomi:
> It's nice for people creating system packages when you specify all of the
> packages that your runtime depends on in setup.py.

So apparently there are others who read and value this information.

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [buildout] RFC: buildout support for distribute

[Hanno Schlichting]

On Tue, Oct 13, 2009 at 9:02 PM, Jim Fulton  wrote:
> I plan to add explicit buildout support for distribute.  Here's a
> sketch. Basically it boils down to satisfying requirements for
> setuptools with distribute whenever distribute is in buildout's
> working set.  So, when installing a package that requires setuptools,
> it will convert that requirement to a requirement for distribute.
> There will be 2 separate bootstrap scripts, one that uses distribute
> and one that uses setuptools.  There will also be a buildout
> configuration option that will allow a buildout configuration author
> to fix which is used.  Probably:
>
> use-distribute = true
>
> This will only serve as a check that the right bootstrap was used.

Sounds good. Tarek already implemented the separate bootstrap file
including the requirements conversion. This is currently done via
monkey-patches of buildout, which could be avoided if this finds its
way into buildout itself.

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Distribute support added in zc.buildout

[Hanno Schlichting]

Hi Tarek,

On Fri, Oct 23, 2009 at 11:46 AM, Tarek Ziadé  wrote:
> I have added in zc.buildout trunk the Distribute support.

Cool!

> The unified bootstrap now has a --distribute boolean option that
> allows you to switch if you want.

What is the easiest / recommended way to tell the bootstrap to use
distribute by default?

I could live with a clear DEFAULT='setuptools' line at the top of the
module, so even if one changes that line, the diff to the original
isn't too large. Otherwise some config file would be the next but more
complicated option.

Thanks,
Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Problems with setuptools 0.6c11, Mac OS X 10.6, Python 2.4 from MacPorts

[Hanno Schlichting]

On Thu, Dec 10, 2009 at 12:10 AM, Jeff Shell  wrote:
> In setuptools 0.6c11, since the change in `pkg_resources._macosx_vers`
> to use `platform.mac_ver`, the MacPorts build(s) of Python 2.4 do not
> seem to be reporting any information out of mac_ver(), causing
> pkg_resources to report spurious information:

This has already been reported as a bug in macports at
https://trac.macports.org/ticket/22278.

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] zc.buildout - macros extending macros

[Hanno Schlichting]

On Wednesday, March 3, 2010, Martin Aspeli  wrote:
[...]
> Unfortunately, the options from [instance] don't seem to make it into 
> [instance1] or [instance2]. In other words, the macro doesn't seem to be 
> evaluated "transitively".
>
> Am I doing something wrong, or is this just not supported?

This is just not supported at the moment. Macros don't work recursively.

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] setuptools dependencies failure and wildcards

[Hanno Schlichting]

On Sun, Mar 14, 2010 at 11:16 AM, Nicholas Bower  wrote:
> 1) Shapely will not work.  The available packages are;

[..] can't help with this question

> 2) How does one say "the latest release of sqlalchemy 0.5.x".
> Unfortunately <0.6 picks up 0.6beta and I can see no way to do
> wildcards in the docs and just say "give me the latest 0.5 series".

You can specify:

<0.6dev

which excludes any development and pre-final versions of the 0.6
series. If that looks strange to you, you could also say:

<0.5.999

assuming it is unlikely the package ever gets a 999 maintenance release.

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] easy_install not working

[Hanno Schlichting]

On Thu, Nov 24, 2011 at 12:44 PM, Tarek Ziadé  wrote:
> Please try to update your installation to the latest revision of
> Distribute. You currently have 0.6.21 and it seems that somehow it's
> in a broken state
>
> $ easy_install-2.7 -U Distribute

That should probably be a lower case d:

$ easy_install-2.7 -U distribute

> (with sudo rights if needed)

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] getting the local site_packages

[Hanno Schlichting]

On Wed, Feb 1, 2012 at 4:08 PM, Andrea Crotti  wrote:
> With something like this
> site_packages = pkg_resources.get_python_lib()
>
> I get the python global path of the site-packages directory, is there a way
> to get also
> the local one, which for example on Linux might be something like
>
> $HOME/.local/lib/site-packages

What does import site; site.getusersitepackages() return - as per
http://docs.python.org/library/site.html#site.getusersitepackages

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] Fwd: Adding a "Pure Python" flag to PyPI

[Hanno Schlichting]

On Mon, Mar 5, 2012 at 10:21 PM, "Martin v. Löwis"  wrote:
> However, downloading the source distribution and inspecting it should
> be fairly reliable.

Depends on what you want to find out. I know a bunch of packages which
contain optional C extensions. These certainly aren't pure-python and
contain C files in their source distributions. But during "setup.py
install" they'll catch any compilation errors and skip the extension
build step. So they are perfectly usable without a C compiler. Or they
employ even more logic in their setup.py files and make the C
extension conditional on the current platform - like disabling them in
PyPy or Jython.

Just two examples are zope.interface and Jinja2, which has an entirely
optional C extension via setuptools feature support.

I guess all I'm asking for is a better name that makes the intent clearer.

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [buildout] branches languishing? (site-packages and distutils scripts)

[Hanno Schlichting]

On Sun, Mar 25, 2012 at 10:12 PM, Reinout van Rees  wrote:
> - Where to put it on github? Is there a zope or zope corp or Jim account
> that's the best place to put it?

I'd suggest the creation of a separate buildout organization. Such a
place might over time also get a collection of various recipes,
zc.recipe.egg / zc.recipe.cmmi being prime examples.

There is a non-sanctioned https://github.com/zopefoundation which I
have control of. But as there's really nothing Zope specific about
buildout, I wouldn't want to continue associating it with Zope.

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [buildout] branches languishing? (site-packages and distutils scripts)

[Hanno Schlichting]

On Sun, Mar 25, 2012 at 11:31 PM, Jim Fulton  wrote:
> Hanno suggested creating a buildout organization.  I'm up with that.
> Maybe someone can create one and include me. :)

In case you want it, there you go: https://github.com/buildout/buildout

Jim is a co-owner of the organization having admin access, the
developers team with pull/push rights is currently empty.

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [buildout] branches languishing? (site-packages and distutils scripts)

[Hanno Schlichting]

On Mon, Mar 26, 2012 at 1:46 PM, Reinout van Rees  wrote:
> On 26-03-12 13:41, Jim Fulton wrote:
>> Does anyone have any objections to renaming the project "buildout"?
>
> Rename is fine with me.

+1

But there's about 20 or so packages on PyPi using buildout as a
namespace package. That'll work just fine, as long as the new buildout
puts the magic into its top level __init__.py and has no other code
there.

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] [buildout] branches languishing? (site-packages and distutils scripts)

[Hanno Schlichting]

On Mon, Mar 26, 2012 at 4:38 PM, Jim Fulton  wrote:
> On Mon, Mar 26, 2012 at 7:54 AM, Hanno Schlichting  wrote:
>> That'll work just fine, as long as the new buildout
>> puts the magic into its top level __init__.py and has no other code
>> there.
>
> No, it won't. You can't count on the order that namespace packages get
> scanned, so you really can't have code in __init__.py if you want to
> count on it getting installed.

That's my point. As long as every buildout/__init__.py contains the
setuptools namespace code and nothing else, all is fine. So as long as
the new buildout distribution does the same, it'll all work.

I'm not aware of any problems with having modules directly inside a
namespace package. So a buildout/easy_install.py should be importable
via "from buildout import easy_install".

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] setuptools feature: tag_git_description like tag_svn_revision

[Hanno Schlichting]

On Sun, Apr 22, 2012 at 5:22 PM, Jasper van den Bosch  wrote:
> Might it be an idea to have an option like 'tag_git_description' similar to
> tag_svn_revision? A possible implementation could use git describe; such as
> suggested by Douglas Creager in this gist: https://gist.github.com/300803. I
> am currently using this for my packages, but it might be nice to integrate
> it into setuptools.

The automatic SVN support is pretty controversial in setuptools and at
least for distribute we more or less decided to not expand it further.

But there's various revision control specific packages, you can use:

http://pypi.python.org/pypi/setuptools-git
http://pypi.python.org/pypi/setuptools_bzr
http://pypi.python.org/pypi/setuptools_hg
http://pypi.python.org/pypi/setuptools_subversion (for SVN 1.7+)

If you have git specific ideas, it's best to follow up with the
maintainers of setuptools-git.

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] unneeded warning about missing readme in case of rst

[Hanno Schlichting]

On Mon, Jun 25, 2012 at 1:44 PM, Reinout van Rees  wrote:
> warning: sdist: standard file not found: should have one of README,
> README.txt
>
> The reason for the missing file is that it is called README.rst now because
> bitbucket and github pick up that extension. Is there something that can be
> done about this warning?

I think this got changed in distribute for version 0.6.27. From the changelog:

Distribute now recognizes README.rst as a standard, default readme file.

Not sure if this needs changes on the PyPi server end.

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] patch distutils to look into .dist-info directories

[Hanno Schlichting]

On Mon, Jun 25, 2012 at 8:35 PM, Daniel Holth  wrote:
> OK I'll do that. Of course it also means the code won't work on Python
> < when e-mail.parser was introduced.
>
> What is the floor on Python versions for distutils?

distribute and setuptools try to support Python >= 2.3 - though the
earlier versions have likely seen less testing as of late.

Not sure if you really meant distutils, as that is part of Python itself.

> Would it work to
> require Python 2.6 just for the .dist-info bits?

That's not ideal in any way, but I'd say practicality beats purity
here. So if it's much simpler to write this code for Python 2.6, go
for it.

Hanno
___
Distutils-SIG maillist  -  Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig