Re: [Distutils] Round 6 - PEP 440 - Version Identification and Dependency Specification Version

Paul Moore wrote: FWIW, it looks like file:myserver/share/WINDOWS/clock.avi is how you'd refer to \\myserver\share\WINDOWS\clock.avi. Where did you get that from? According to this it's wrong: http://blogs.msdn.com/b/ie/archive/2006/12/06/file-uris-in-windows.aspx It should be file://

Re: [Distutils] depending on setuptools is discouraged?

Matthias Klose wrote: Most packages need a dependency on pkg_resources only. So adding a pkg-resources egg would be nice. I thought that making pkg_resources a separate thing was one of the goals of the new distutils regime. Has it not happened yet? -- Greg

Re: [Distutils] Call for information - What assumptions can I make about Unix users' access to Windows?

Donald Stufft wrote: For RDP on OSX, Microsoft has a free RDP app: https://itunes.apple.com/us/app/microsoft-remote-desktop/id715768417 And here's another one that I find to be slightly better: http://cord.sourceforge.net/ -- Greg ___ Distutils-SIG

Re: [Distutils] Implementing large changes in small increments

On 03/06/2015 11:06 AM, Ben Finney wrote: That's “small changes only, otherwise your change gets rejected”, of course. Yes, otherwise submitting a patch that replaces the entire source code of Python with Ruby would be a sure-fire way to get it accepted. :-) -- Greg _

Re: [Distutils] Installing packages using pip

On Tue, 08 Dec 2015 08:56:49 +0200, [email protected] wrote: Not sure what exactly was going on but whenever I did that on linux I got the most peculiar segfaults and failures. It is certainly not a safe thing to do, even if linux lets you do it. Are you sure you were actually unlinking the o

Re: [Distutils] Incorrect detection of 32/64-bit arch on Linux for old 32-bit VMs migrated to 64-bit kernels

Nathaniel Smith wrote: The problem seems to be that distutils.util.get_platform() assumes that the architecture is whatever uname's "machine" field says (equivalent to uname -m). Unfortunately, this gives the architecture of the kernel, not of the Python interpreter. I think the fix is that we s

Re: [Distutils] Fwd: setup('postinstall'='my.py')

Leonardo Rochael Almeida wrote: On the other hand, I don't think there's a post-install in the usual way of installing things on the Mac. It's just a folder that is dragged into another folder (not a Mac user myself, so I could be wrong, there could be some side effects on this action). A lo

Re: [Distutils] How to deprecate a python package

Geoffrey Spear wrote: I don't have an answer to your actual question, but I'd not advocate people removing packages; we don't want a npm situation here. :( Perhaps there should be a way of marking a package as deprecated on PyPI, so that it shows a big red warning flag? -- Greg ___

Re: [Distutils] The mypy package

Why are you so determined to use the name "mypy" in the first place? Seems to me it's a terrible name. It sounds more like a working title for someone's personal implementation of Python, and certainly gives no clue that it has anything to do with type checking. So instead of trying to steal the

Re: [Distutils] Parked Names in PyPI under user rodmena

Nick Coghlan wrote: Naming projects in general is hard though, especially for relatively arcane tasks like typechecking annotated Python code. Maybe obtaining a public name on PyPI should be a little bit harder than just using the first name that comes into one's head? Such as getting approval

Re: [Distutils] moving things forward

Chris Barker wrote: OK -- that's more or less my thought -- if it's python that gets run, then you've got your config generator built in -- why not? The difference is that the config generator only gets run once, when the config info needs to get produced. If the config file itself is executa

Re: [Distutils] moving things forward

Chris Barker wrote: This is python packaging, I'm still trying to see why you'd need to read the config without python available. Even if python is available, you might not want to run arbitrary code just to install a package. If a config file can contain executable code, then it can contain b

Re: [Distutils] moving things forward

Chris Barker wrote: But I think there is consensus here that build systems need to be customisable -- which means arbitrary code may have to be run. I think different people are using the word "build" in different ways here. To my mind, "building" is what the developer of a package does, and a

Re: [Distutils] moving things forward

Paul Moore wrote: Do you expect that projects ... should (somehow) contain simplified instructions on how to build the various C/Fortran extensions supplied in the bundle as source code? Essentially, yes. I'm not sure how achievable it would be, but ideally that's what I'd like. would the us

Re: [Distutils] comparison of configuration languages

Having looked over the TOML spec, I like the simplicity of it (and I cringe from the complexity of YAML). The only thing I don't like about TOML is the way it cops out on nesting. The only reason it does that as far as I can see is because of a dislike for significant indentation. But that doesn'

Re: [Distutils] How to handle launcher script importability?

PJ Eby wrote: (Granted, I can see reasons for not wanting to use the same extension for source and zipped versions, mostly in the area of tools other than pylauncher, but if you do have different extensions then there have to be *four*, due to console vs. windowed and source vs. zipped.) Just a

Re: [Distutils] Multi-version import support for wheel files

Daniel Holth wrote: I would like to see some consideration given to what Ruby and npm do, which is to place what we are calling dists into a special directory that only contains dists /somedir/distname-1.0/... rather than placing them as specially named objects on the normal search path. What a

Re: [Distutils] Plans for binary wheels, and PyPi and OS-X

Chris Barker wrote: anyone putting a [MacOSX] binary on PyPi has an obligation to built is so it will work with the python.org python -- and it's not inherently any harder to do that than on Windows Is there some way that a wheel could be checked to make sure it doesn't de

Re: [Distutils] Plans for binary wheels, and PyPi and OS-X

Paul Moore wrote: Python version - cpXY Platform - distutils.util.get_platform(), which is "darwin" for OSX, if I'm reading the code correctly. ABI - essentially sysconfig.get_config_vars().get('SOABI') if that exists Does the MAXOSX_DEPLOYMENT_TARGET figure into this anywhere? Just knowing tha

Re: [Distutils] Plans for binary wheels, and PyPi and OS-X

Donald Stufft wrote: python -c "import distutils; print(distutils.util.get_platform().replace('.', '_').replace('-', '_'))" macosx_10_8_x86_64 Hmm, this just appears to reflect the version of MacOSX that the Python running distutils was built on, or is running on (not sure which). This is not

Re: [Distutils] Using Wheel with zipimport

Nick Coghlan wrote: Otherwise we'd have to define a whole new format for something that can be adequately handled by a wheel that meets certain restrictions, and that would be pointless (we already have too many formats, and we wanted the wheel format to offer a strict superset of the egg format'

Re: [Distutils] [Python-Dev] The Breaking of distutils and PyPI for Python 3000?

Jeff Rush wrote: > Perhaps it is time for a parallel rewrite, > so that those setup.py who import distutils get the old behavior, and those > who import distutils2 get the new, That sounds good to me. If anyone wants to have a go at this, I have some ideas on how to structure it that I'd be happ

Re: [Distutils] [Python-Dev] PEP 365 (Adding the pkg_resources module)

At 12:58 AM 3/20/2008 -0400, Tres Seaver wrote: > A lot of setuptools warts are driven by related design problems in the > distutils, such as the choice to use imperative / procedural code for > everything If a distutils replacement is ever written, I'd like to see it structured as a dependency g

Re: [Distutils] how to easily consume just the parts of eggs that are good for you

Paul Moore wrote: > I believe that Mac OS X goes for an even simpler structure - > applications store *everything* in the one directory, so that > install/uninstall is simply a directory copy/remove. Yep, and thereby cuts the whole gordian knot, throws the pieces on the fire and burns them. :-)

Re: [Distutils] [Python-Dev] how to easily consume just the parts of eggs that are good for you

Paul Moore wrote: > And I would say that Windows doesn't have a problem. Are any Windows > users proposing building a package management system for Windows > (Python-specific or otherwise)? It's a genuine question - is this > something that Windows users are after, or is it just Linux users > tryin

Re: [Distutils] how to easily consume just the parts of eggs that are good for you

John J Lee wrote: >> I keep hoping that someday Linux will support something >> like MacOSX application bundles and frameworks, > > Not the same, but "something like": > > http://0install.net/ That looks interesting, but I'm not sure I'd quite call it "something like". It looks like another case

Re: [Distutils] how to easily consume just the parts of eggs that are good for you

John J Lee wrote: > It allows you to think about "uninstallation" as "delete the app == > delete the file" But 0install doesn't do that, as far as I can tell -- it still keeps the data in some mysterious form and location known only to itself, and requires you to use special tools to install/rem

Re: [Distutils] shebang line modified by setuptools

Gael Varoquaux wrote: > a second Python > needs to be installed on top of the system Python to add modules to it. Maybe the system should come with two pythons installed, one for use by the system and the other for users to add things to. Or at least be set up so that it appears that way -- they m

Re: [Distutils] how to easily consume just the parts of eggs that are good for you

John J Lee wrote: > If you have a network connection, about the only reason for not wanting > an app to be "installed" is that it has changed the behaviour of your > system somehow, just by being in the "installed" state. If you have a continuous high-speed network connection and aren't concerne

Re: [Distutils] how to easily consume just the parts of eggs that are good for you

David Cournapeau wrote: > There are two ways of looking at it, I think. One is to think that linux > FHS (and unix in general) is totally broken. I don't think it's *totally* broken. I do think it goes overboard with splitting things up and scattering them around. I understand that there are reas

Re: [Distutils] shebang line modified by setuptools

Gael Varoquaux wrote: > On Mon, Apr 14, 2008 at 01:30:14PM +1200, Greg Ewing wrote: > > > Maybe the system should come with two pythons installed, > > What you propose resembles very much to what MacOSX does... I see on the > different scientific-Python-related mailing

[Distutils] Simple idea to resolve versioning problems

David Cournapeau wrote: > what is needed is a stable API for the used packages. That's a nice ideal to aim for, but it's only achievable for old and mature packages. One could change the package name every time the API changes, but then *any* change to the API would make the package unusable by a

Re: [Distutils] Simple idea to resolve versioning problems

David Cournapeau wrote: > Library versioning without API > stability just does not make sense to me. Yes, obviously if you have library versioning you need to use it properly in order for it to be any use. > How do you do if you have a package D > which depends on both C and B, and C needs one

Re: [Distutils] Simple idea to resolve versioning problems

Paul Moore wrote: > Is nobody but me seeing shades of Windows "DLL hell" in all of this? I think DLL Hell occurred partly because people *didn't* distinguish different API versions clearly with different file names. Also because programs were allowed to put shared stuff in the system directory w

Re: [Distutils] Simple idea to resolve versioning problems

David Cournapeau wrote: > Greg Ewing wrote: > > > If they really do need different versions, this is insoluble. > > But that's by far the most significant problem of packages with a lot of > dependencies ! But if your application really does depend on two libra

Re: [Distutils] Simple idea to resolve versioning problems

David Cournapeau wrote: > Greg Ewing wrote: > > > the earlier versions would *never be used* > > even if they were installed. > > What's the point of having it installed, then ? I am confused. I never said there was a point. When I mentioned multiple installed

Re: [Distutils] [Python-3000] sizeof(size_t) < sizeof(long)

David Cournapeau wrote: > I ask for "256 Mo", Mo for Mega-octet: French (and most non English > languages I am aware of) does not have this ambiguity :) But would you ask for it that way in an English-speaking country? Would they have a clue what you were talking about? Anyway, I don't think it

Re: [Distutils] Simple idea to resolve versioning problems

Jeff Younker wrote: Thats a great theory, but that's not how the real world works. Python packages are an ecology where there will be inconsistencies between different minor versions of the same package. I'm not sure what you're arguing here. If you're saying that having a version management

Re: [Distutils] [Python-Dev] shal we redefine "module" and "package"?

Nick Coghlan wrote: zooko wrote: Q1. You type "import foo" and it works. What kind of thing is foo? foo is a package or a module. Not enough information is provide here to say which. Actually, it could be anything! But it's *probably* a module (or package, but a package is also a module,

Re: [Distutils] [issue6] all files installed +x

Peter Fein wrote: Setuptools installs all files with mode +x (executable), overriding any permissions specified in the original archive. ALL files? Literally? If that's true, then on Unix this is astonishingly wrong and definitely needs to be fixed. -- Greg __

Re: [Distutils] [issue24] Rename easy_install

Jeroen Ruigrok van der Werven wrote: -On [20080614 03:18], zooko ([EMAIL PROTECTED]) wrote: I said it was "too late", because there are already lots of people worldwide who know the name "easy_install". Nothing proper release notes and the likes cannot fix. My objection to the name "easy_i

Re: [Distutils] [issue24] Rename easy_install

Phillip J. Eby wrote: What do you mean, "sounds like"? It *is* marketing propaganda. And it worked very well, I might add. ;-) Maybe on some people, but I tend to get turned off by that sort of thing. In any case, if it gets into the core, then the marketing aspect will have done its job a

Re: [Distutils] [Fwd: Re: Annoucing distribute project]

Guido van Rossum wrote: Yeah, but *is* dropping backward compatibility an option here? I'm not sure the concept of backward compatibility makes sense here. The only kind of distutils replacement I would be interested in would have a completely different API, completely different structure and

Re: [Distutils] [Fwd: Re: Annoucing distribute project]

Guido van Rossum wrote: You're not building a brand new bridge where there was no bridge before. You're trying to upgrade an existing bridge that people use for their daily commute. But that hasn't been decided. Whether to upgrade the existing bridge or build a new one is precisely what we're

Re: [Distutils] [Fwd: Re: Annoucing distribute project]

Phillip J. Eby wrote: the domain knowledge embedded in the distutils are of fairly limited scope and kind: * Extension building, compile/link options and defines * Wildly-differing installation path schemes across platforms * Platform distribution formats like bdist_rpm, bdist_wininst, and bd

Re: [Distutils] [Fwd: Re: Annoucing distribute project]

Tres Seaver wrote: I think a tool which was willing to fake being distutils enough to extract information from existing 'setup()' calls would probably be enough, myself, so that: $ python .py setup.py would create the equivalent of PKG_INFO / EGG_INFO on disk, where it could then be used to d

Re: [Distutils] backwards compatibility for packaging tools

zooko wrote: So we should focus on documenting and standardizing the metadata that allows code re-use -- the interface between the author of one package and the author of another package -- not the interface between the author of a package and the tool that he uses to build and distribute

Re: [Distutils] [pyconuk] "just use debian"

Josselin Mouette wrote: if you try to build a package of baz, there is no way to express correctly that you depend on python-bar (>= 1.3) or python-foo (>= 1.2). Seems to me that baz shouldn't have to say that -- all it should have to say is that it requires bar version 1.3. It's up to the pack

Re: [Distutils] PEP for distutils

Ian Bicking wrote: FWIW, pyinstall can collect all the packages before installing any of them. You do have to download all packages, though, as that's the only way to get the metadata. This may be something to make sure is on the requirements list for a metatdata standard: Make sure there is

Re: [Distutils] [pyconuk] "just use debian"

Josselin Mouette wrote: Le mardi 30 septembre 2008 à 17:20 +0200, Tarek Ziadé a écrit : > > I mean, if you change a public API of your package , you *have* to > change its name ? Yes, this is the requirement for C libraries, and we try to enforce it as well for other languages. Things are so

Re: [Distutils] "Python Package Management Sucks"

Toshio Kuratomi wrote: this is what I was afraid of. This is definitely not a definition of resource-only that has meaning for Linux distributions. None of the data in /usr/share is user-modifiable In that case it must be there because it's architecture-independent, right? But by that crit

[Distutils] AMP, anyone? (Re: "just use debian")

David Cournapeau wrote: when you change the soname of a library, it has 0 impact on the source code of the software which links against it. That's not true in python. In the Eiffel world, there's a thing called an ACE, which stands for Assembly of Classes in Eiffel. It's a way of specifying a

Re: [Distutils] "Python Package Management Sucks"

Jeroen Ruigrok van der Werven wrote: -On [20081002 13:29], Josselin Mouette ([EMAIL PROTECTED]) wrote: There’s definitely no problem with shipping them in an egg, as long as it is possible to ship them at standard locations. Standard according to whom though? I think the idea is to *define*

Re: [Distutils] "Python Package Management Sucks"

Phillip J. Eby wrote: Where data files are concerned, however, a developer should only need to distinguish between read-only, read-write, and samples, because any finer-grained distinction that relies on platform-specific concepts (like locale directories) is probably going to be error-prone.

Re: [Distutils] "Python Package Management Sucks"

On Thu, Oct 02, 2008 at 01:20:45PM +0200, Josselin Mouette wrote: Sorry, but things don’t work this way. Anything that is *not* a .py file should not land in the python module directories. So where *should* they go, on platforms where there is no defined place for such things? And how can the c

Re: [Distutils] AMP, anyone? (Re: "just use debian")

David Cournapeau wrote: Do you have a link toward this. I could not find much info with google on this Assembly Classes for Eiffel. It seems to be difficult to find any in-depth information about it on the web. There's a summary of the syntax here: http://archive.eiffel.com/nice/language/pag

Re: [Distutils] Symlinks vs API -- question for developers

Toshio Kuratomi wrote: So once again, I think this boils down to these questions: if we have a small library whose sole purpose is to abstract a data store so you can find out where a particular non-code file lives on this system will you use it? As part of the stdlib? Yes, I'd use it. -- Gre

Re: [Distutils] Symlinks vs API -- question for developers

Josselin Mouette wrote: Then, you need to flag your icons; this is what you already proposed, in a more sophisticated way. foo.png: icon size="48x48" category="apps" foo.svg: icon size="scalable" category="apps" This smells like overdesign to me. Unless you want to allow for th

Re: [Distutils] Symlinks vs API -- question for developers

Josselin Mouette: Unless you want to be able to follow existing standards. http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#directory_layout All you need for that is a category called "icons". I don't see anything there about putting different sizes of icon in diff

Re: [Distutils] Distutils changes - end user requirements (Was: Deprecate MANIFEST.in)

Paul Moore wrote: If I have to guess at your reasons, my assumption would be: - Consistent means of installing on all platforms - ??? I can imagine that people for whom Windows is not their primary platform might like to be able to install Python packages the same way they do on other platform

Re: [Distutils] Distutils changes - end user requirements (Was: Deprecate MANIFEST.in)

Paul Moore wrote: Personally, I'd be happy if every package that currently distributes any form of Windows binaries, distributed a Windows installer. ... > I agree that expecting *everything* to have a Windows installer is unreasonable. Would it be feasible to have a generic installer for .e

Re: [Distutils] The problem with Setuptools on Python 3.

Lennart Regebro wrote: We need a plan. Somebody please make a plan Whatever plan you come up with, I'd like to see the basic architecture built around a dependency graph, at least for the parts concerned with building extension modules from sources. My use case for handling Pyrex sources. I'd

Re: [Distutils] The problem with Setuptools on Python 3.

Tarek Ziadé wrote: Please Greg, add your use case here with David's one, at the end of the page, since we are trying to work on a solution. http://wiki.python.org/moin/Distutils/ManifestPluginSystem/Draft Is this really the best place for it? My use case doesn't have anything to do with manife

Re: [Distutils] Adding entry points into Distutils ?

Paul Moore wrote: That works but a lot of Unix users have in the past objected to having '.py' in the name. So install a symlink from hello -> hello.py. -- Greg ___ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/l

Re: [Distutils] Announcing the 'Distribute' project

Kent Tenney wrote: I thought a good name was considered important. Are there any Monty Python sketches that relate to packaging or distribution? That's the only way to find names for really *important* things in Python.:-) -- Greg ___ Distutils-SIG

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

Ben Finney wrote: Also, there never really was a “setuptools 1”. I think it's only going to be confusing to call this “setuptools 2”. Return of Setuptools? Revenge of the Setuptools? Setuptools Strikes Back? -- Greg ___ Distutils-SIG maillist -

Re: [Distutils] Announcing the 'Distribute' project

Ben Finney wrote: Fails the web search test: a search for “python packaging” will not find this project specifically. The same criticism probably applies to "distribute", which seems to be ahead in the poll right now. -- Greg ___ Distutils-SIG mail

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

Ben Finney wrote: Huh? A dictatorship doesn't involve a poll. Nonsense, it's perfectly legitimate dictatorial behaviour to have a poll - you just have to make sure you know what the result will be. :-) (Of course it's a good idea to first check that you have enough security forces on hand to

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

At 04:54 PM 7/18/2009 +0200, Joachim König wrote: > - upsettools because it upsets a lot of people +10 -- that's brilliant! -- Greg ___ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig

[Distutils] Cache PYTHONPATH? (Re: make unzipped eggs be the default)

P.J. Eby wrote: So the optimum performance tradeoff depends on how many imports you have *and* how many eggs you have on sys.path. If you have lots of eggs and few imports, unzipped ones will probably be faster. If you have lots of eggs and *lots* of imports, zipped ones will probably be fas

Re: [Distutils] Configuration via imperative or declarative language (was: Static metadata using setup.cfg)

Ben Finney wrote: The metadata being discussed is static. What's at issue is how that metadata should be encoded: in an imperative language (like a Python program file) or a declarative language (like a ConfigParser file). I'm not sure that exactly expresses the distinction either. Depending o

Re: [Distutils] Static metadata using setup.cfg

Tarek Ziadé wrote: In that case, if we want to keep a configparser-compatible file, we need to find another way to express these if/else parts, which will probably lead to a complex, non natural syntax. Maybe the conditions could be expressed in the section headers? [requires platform="linux"

Re: [Distutils] Static metadata using setup.cfg

Tarek Ziadé wrote: long_description: {$ long_description('README.txt') $} A couple of thoughts: 1. Is there anything about this function that would restrict it's use to the long_description field, or could it be called something more general like "from_file" and used in other contexts? 2. I'

Re: [Distutils] Static metadata using setup.cfg

David Lyon wrote: or just.. [requires linux2] ... [requires win32]: ... Perhaps, if the sets of "tokens" used in the various fields one might be interested in are disjoint. It would require more intelligence from tools processing the data, though, and might be harder to extend to accommodate

Re: [Distutils] setup.cfg new format proposal

Tarek Ziadé wrote: > [setup] > foo: bar > conditional-sections: one, two Is conditional-sections: really necessary? Isn't the presence of a conditions: line in a section enough to mark it as conditional? -- Greg ___ Distutils-SIG maillist - Distutil

Re: [Distutils] setup.cfg new format proposal

Tarek Ziadé wrote: I find having a conditional section explicitely defined better that doing a convention on names because if someone implements a command that uses that name (it's likely to be improbable but...) it will break his ability to use setup.cfg to give options to his commands I don'

Re: [Distutils] setup.cfg new format proposal

Tarek Ziadé wrote: Imagine a command with the name "foo", that has an option called "condition". If you really want to keep the entire keyword namespace available for use as a section sees fit, it would be better to put the conditions inside the section headers, as I suggested earlier. I thin

Re: [Distutils] setup.cfg new format proposal

Sridhar Ratnakumar wrote: >>> sys.platform 'linux2' "linux2"? What are the possible values for `sys.platform`? This is why I usually write Python code that checks sys.platform like if sys.platform.startswith("linux"): ... So the condition language for the metadata needs a "start

Re: [Distutils] setup.cfg new format proposal

Tarek Ziadé wrote: What about 'in' ? Yes, I guess that's good enough. -- Greg ___ Distutils-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/distutils-sig

Re: [Distutils] the virtualenv-distribute mess

Reinout van Rees wrote: OTOH, grumbl ... horrible breakage ... essential piece of infrastructure ... allowed to persist I'm pretty grumpy right now. I'd just like to point out that if anyone finds setuptools to be "essential" to them, it's because they've chosen to make themselves depende

Re: [Distutils] People want CPAN :-)

David Cournapeau wrote: One of the main argument to avoid rewrite is that you will end up doing the same mistakes, and old code is more complicated because it has been tested. But here, we know what a good design is like as other languages have vastly superior solutions to this problem. Also, i

Re: [Distutils] People want CPAN :-)

Tarek Ziadé wrote: If the answer to that solution is just: "Distutils sucks anyways..", it is not really helpfull imho.. I don't see the point to write Distutils from scratch, instead of making it evolve. If you can see a way to get from the current distutils code to something with a well-des

[Distutils] Build_ext refactoring (was: People want CPAN)

David Lyon wrote: The parts that shouldn't be rewritten (because the people that wrote it were too clever - and the degree of difficulty to high) is any C interface. Not exactly sure what you mean by that. If you mean the knowledge of how to call the C compiler to compile an extension module o

Re: [Distutils] People want CPAN :-)

Robert Kern wrote: With all respect to Greg Ward and the rest of the original distutils authors, it was a fantastic improvement over the state of affairs ten years ago, but we've learned a lot about application frameworks and about building software since then. I think we knew more about it *

Re: [Distutils] People want CPAN

Tarek Ziadé wrote: On Thu, Nov 12, 2009 at 12:03 AM, David Cournapeau wrote: You cannot obtain this with classes and objects (especially when you start talking about performance: thousand of source files for one extension is not a crazy usercase). Sorry, I am getting confused here. This is

Re: [Distutils] People want CPAN

Tarek Ziadé wrote: And have the community create new ExtensionBuilder subclasses that could be registered like command. I don't see a need for registering anything. You should just be able to explicitly say what tool to use for each stage of the process. I envisage something like this: fro

Re: [Distutils] People want CPAN

Tarek Ziadé wrote: But the result is similar, and explicit imports should work too, so maybe registeries are just sugar on the top of something we first need to make work. It's completely unnecessary sugar, if you ask me. I don't see what's bad about importing functionality you want to use. W

Re: [Distutils] Common version-comparison semantics for peace love and harmony

Laura Creighton wrote: Now I want to say 'requires this bugfix'. Right now I think that if I say requires 1.0.2 or later, then people with 1.1 will expect that they are ok, when they are not. Or am I misunderstanding? In cases like that, I don't think any scheme that relies on comparing with

Re: [Distutils] FAQ (was: Re: Bootstrap script for package management tool in Python 2.7)

Tarek Ziadé wrote: For me a FAQ is a list of questions. We add a new question everytime someone ask it and it doesn't exists. The point is that the "FA" in "FAQ" stand for *frequently asked*. One can debate how frequent is necessary to be placed in this category, but a question that has only

Re: [Distutils] Bootstrap script for package management tool in Python 2.7 (Was: Re: [Python-Dev] At least one package management tool for 2.7)

anatoly techtonik wrote: Let's refer to original user story: ... "I execute `easy_install something` as said in installation manual, but nothing/error happens." Which installation manual did the user see that in? It can't be anything that came with Python, because easy_install is not a standar

Re: [Distutils] install --dry-run broken?

Jim Fulton wrote: The documentation says that when --dry-run is used: "don't actually do anything". This is not the actual behavior. I'd be happy to see the option go away. I wouldn't! I find it useful for testing a setup.py that I'm about to distribute, to make sure it isn't going to fall o

Re: [Distutils] install --dry-run broken?

On 23/04/10 15:11, Ben Finney wrote: Are you saying that the feature does work as described? All I can say is that I haven't noticed that it doesn't. I've never actually bothered to check, because it never occurred to me before that it might be broken. I'll look into it and report back. -- Gr

Re: [Distutils] install --dry-run broken?

P.J. Eby wrote: The problem is that the build is also a dry run, so the files aren't there for the later bits to actually copy. That's not a problem for me, because I'm not trying to find out what will get copied. I only use --dry-run to exercise my setup.py code to make sure it doesn't crash.

Re: [Distutils] Design rationale for the egg format ?

Paul Moore wrote: On 14 June 2010 07:59, David Cournapeau wrote: - why does the filename encode some metadata (which python version if the package contains extensions, platform specifier) ? I believe that this is so that the basic metadata can be obtained as part of an initial listdir() It

Re: [Distutils] Packaging situation + mailing list rules

Tarek Ziadé wrote: 4. Distribute forks Setuptools for various reasons. If you disagree with this choice, there's no need to send a mail here David isn't disagreeing with that choice, as far as I can see. The *only* thing he's saying is that the fork should have a different name, because it's a

Re: [Distutils] Packaging situation + mailing list rules

Éric Araujo wrote: Distribute is a fork of Setupools, so it wants to be a drop-in replacement, i.e. to be used instead of setuptools with very few code changes. But is there a technical reason why it *has* to be a drop-in replacement, as opposed to a different package with a different name? -

Re: [Distutils] `setup.py register` can't create PyPI account.

Martin v. Löwis wrote: For backwards compatibility, I'm willing to accept solutions as long as they don't allow users to bypass that checkbox. If the user is required to visit a web page to complete the registration, could you put the check box on *that* page instead? -- Greg ___

Re: [Distutils] Name the software! Package quality tester.

Lennart Regebro wrote: But, before I move this to a public repository and upload it to PyPI, there is one important thing to be determined: What should it be called? Inspector Tiger? http://www.youtube.com/watch?v=UDdCghQYvDY -- Greg ___ Distutils-

Re: [Distutils] Name the software! Package quality tester.

Lennart Regebro wrote: If a decision comes to call these "projects", then I'm fine with that, +1 on 'project' as the official term. A bonus is that we could decide that PyPI stands for Python Project Index if we wanted. -- Greg ___ Distutils-SIG mai

Re: [Distutils] Name the software! Package quality tester.

Jim Fulton wrote: If what we now call "packages" were called "modules", then we could start using the term "package" the way everyone else does. But then we would not have a term for a module that corresponds to a directory rather than a single .py file. -- Greg __

  1   2   >