Re: [Distutils] PEP 517 again
Nathaniel Smith wrote: - creating an sdist failed for unexpected reasons, that need a human to sort out (due to a broken system, or bugs – hey, they happen – or ...) I think that should still be reported via an exception. Returning None should only be for the specific case that the backend doesn't support the requested operation. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 517 again
xoviat wrote: I mean how is opening a file different than attempting to build an sdist? 1. Opening a file is a very common operation. 2. Most file opens are expected to succeed, and if one doesn't, the appropriate place to deal with that is almost never at the site of the open call, but somewhere further up. In contrast, there's probably only about one place in any given frontend where the backend's build_sdist method gets invoked, and it's unlikely the ability to let a not-implemented exception bubble up from that point would be of great use. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 517 again
Nathaniel Smith wrote: I now think it should only be a defined return value for get_requires_for_build_sdist and build_sdist, and should have special "sorry I can't do that Dave" semantics that are different from e.g. a missing get_requires_for_build_sdist hook. I don't think there's anything wrong with NotImplemented triggering different actions in different circumstances. It already has very context-dependent "fall back to something else" semantics for binary operators. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 517 again
xoviat wrote: I agree with Nick that exceptions are the way to do things in Python I don't agree that exceptions are the way to do "things" in general. They're the way to so *some* things. The question is whether the thing we're talking about is one of those things. The reasoning behind this is that Python has in general adopted this approach (Nick is right that they would have used NotImplementedError for binary operations except for performance issues) But only because NotImplemented is an out-of-band condition for operations in general. We're not talking about a general operation here, but a very specific one that only has a couple of possible results. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 517 again
Donald Stufft wrote: The thing being bubbled up is a backend accidentally calling an API that has yet to be implemented (an error that should be reported) being bubbled up and erroneously handled as the backend reporting it doesn't support making a sdist (not an error, son no traceback). To my way of thinking, the only justification for using an exception instead of a return value as part of a protocol between a caller and a callee is if you need some kind of out-of-band return value. For example, __next__ can't use a return value to signal end of iteration, because any value could be a legitimate return value. That doesn't apply here, so there's no reason to use an exception. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Fwd: Re: PEP 517 again
Paul Moore wrote: 4. The point of all this is that the definition of build_directory says "If build_directory is None, the backend may do an 'in place' build which modifies the source directory and may produce different results from those that would be obtained by exporting an sdist first". Is it really necessary for pip to specify exactly *where* to do an out-of-place build? Why should it care, as long as the end result is a clean wheel? -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] status check on PEP 517
Thomas Kluyver wrote: I'd like us to circle back round and reconsider allowing projects to specify 'use tool X to make wheels, and tool Y to make sdists'. Seems to me this wouldn't strictly need to be part of the spec, as it could be provided by a multiplexing backend that relays operations to other backends. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] A possible refactor/streamlining of PEP 517
Nathaniel Smith wrote: I think at the moment it's basically only you and me who actually have strong opinions, and everyone else is barely following. I've been a somewhat confused bystander in this thread for a while, and for what it's worth, I think Nathaniel is exactly right on these points: 1. In-place vs. out-of place and sdist/wheel consistency are orthogonal issues. 2. Sdist/wheel consistency should be an implied goal that goes without saying in all cases. Even if a backend can't always guarantee it, it should make a best effort. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Maintaining a curated set of Python packages
Glyph Lefkowitz wrote: "New Project" could just create a requirements.txt and a setup.py for you, alongside a git repo and a virtualenv for that project. Or, the UI could be geared towards setting up a tox.ini rather than a virtualenv, and run everything through tox so it's in an isolated environment with defined requirements. I'd be very interested in something like this. I'm not a big fan of IDEs generally, but one feature I do appreciate greatly is having a one-button "build" process that creates a distributable app bundled with everything it needs, and be assured it will work on someone else's machine. That's currently rather difficult to do with Python in any but the simplest cases, even for a single platform. Cross-platform is even worse. +1 on providing some tools to make it easier. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] PEP 517: Build system API
Thomas Kluyver wrote: - There's a feature called NTFS Junction Points, which is supposed to be like symlinks, but only for directories. Things might have changed, but last time I played with junction points they seemed rather dangerous, because if you deleted one using the GUI it deleted the contents of the directory it was linked to. And it appeared indistinguishible from a normal folder in the GUI, so you got no warning that was about to happen. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
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't apply to us -- we're Python folks, we're not afraid of indentation! On the contrary, for us it's the One Obvious Way to do nesting. So I'd like a format that is very similar to TOML except that you're allowed to represent nesting using indented blocks. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
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 user need to put all the various details of his system into a configuration file somewhere (and update that file whenever he installs a new library, updates his compiler, or whatever)? On a unix system, most of the time they would all be in well-known locations. If I install something in an unusual place or in an unusual way, I'm going to have to tell something about it anyway. I don't see how an executable setup file provided by the package author is going to magically figure out all the weird stuff I've done. I don't know if there are conventions for such things on Windows. I suspect not, in which case manual input is going to be needed one way or another. How would this cope with (for example) projects on Windows that *have* to be compiled with mingw, and not with MSVC? An option to specify which compiler to use would be a fairly obvious thing that the config format should provide. As would a way to include different option settings for different platforms. Combine them in the obvious way. This sounds to me more like an attempt to replace the "build" part of distutils/setuptools with a more declarative system. Not all of it, only the parts that strictly have to be performed as part of the build step of the install process, to use your terminology. That's a fairly restricted subset of the whole problem of compiling software. (Ideally, I would make it *very* restricted, such as only compiling C code (and possibly C++, not sure). For anything else you would have to write a C wrapper or use a tool that generates C. But that might be a step too far.) Could a purely declarative config file be flexible enough to handle this? I don't know. The distutils API is actually pretty declarative already if you use it in a straightforward way. The trouble is that there's nothing to prevent, or even discourage, writing a setup.py that works in non-straightforward ways. I've seen some pretty convoluted setup.py code that worked great when your system happened to match one of the possibilites that the author had in mind, but was very difficult to deal with otherwise. If I'd been able to just set a few compile options and library paths directly, it would have been a lot easier. There's also nothing to prevent the setup.py from doing things that don't strictly need to be done at install time. Running Pyrex to generate .c files from .pyx files is one that I've encountered. (I encouraged that one myself by including a distutils extension for it, which I later decided had been a mistake.) the proposals currently on the table would allow you to ask pip to use that build system rather than setuptools: > [buildsystem] requires=gregsbuild build_command=gregsbuild --make-wheel That's nice, but it wouldn't help me when I encounter a package that *hadn't* been set up to use gregsbuild. :-( -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
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 "build system" is what he uses to do it. I don't care how much arbitrary code gets run during that process. But when I do "python setup.py install" or "pip install" or whatever the recommended way is going to be, from my point of view I'm not "building" the package, I'm *installing* it. Confusion arises because the process of installation may require running a C compiler to generate extension modules. But figuring out how to do that shouldn't require running arbitrary code supplied by the developer. All the tricky stuff should have been done before the package was released. If it's having trouble finding some library or header file or whatever on my system, I'd much rather have a nice, clear declarative config file that I can edit to tell it where to find them, than some overly clever piece of python code that's great when it works but a pain to unravel when it doesn't. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
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 bugs. Debugging is something the developer of a package should have to do, not the user. In my experience, fixing someone else's buggy setup.py is about as much fun as pulling one's own teeth out with a blunt screwdriver. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
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 executable, it needs to be run each time the config info gets *used* -- which could be by a tool for which running arbitrary python code is awkward or undesirable. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
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 from a moderator, or something. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
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 name "mypy", how about coming up with a new, more appropriate name? -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
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 ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
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 lot of Mac software is distributed that way, but not all. There is an installer mechanism, using .pkg files (the moral equivalent of a .msi file) that can run whatever scripts it needs during installation. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
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 should add some check like if osname == "linux" and machine == "x86_64" and sys.maxsize == 2147483647: machine = "i686" If you fix this, please do it for other platforms as well. I encountered the same problem on MacOSX, where for historical reasons I have installed Python and all my compiled-from-source libraries as 32 bit. The result is that py2app includes the wrong version of the stub executable in the apps it builds. Conceivably a similar thing could happen on Windows, although I haven't tested it. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Installing packages using pip
On Tue, 08 Dec 2015 08:56:49 +0200, cont...@ionelmc.ro 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 old file and creating a new one, rather than overwriting the existing file? The latter would certainly cause trouble if you were able to do it. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/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 ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
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 maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
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 ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
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://myserver/share/WINDOWS/clock.avi i.e. the hosthame part of the path goes into the hostname part of the URI, which makes sense. If the path uses a drive letter instead, there is no hostname, so that part of the URI is empty, resulting in three consecutive slashes: file:///c:/WINDOWS/clock.avi -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
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's capabilities). Would it help if zipimportable wheels were given a different extension? The format could be exactly the same (except perhaps for a flag in the metadata) but users would be able to immediately tell whether a particular wheel was zipimportable without having to run a tool. We would need a suitably catchy name for them too. Zippy wheels? Fast wheels? Hotwheels? -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
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 http://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 depend on any libraries in non-standard locations, etc? If not, could enough information be added to the metadata to make it possible? -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
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 that the platform is darwin
isn't really enough.
--
Greg
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
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 quite the same thing as MACOSX_DEPLOYMENT_TARGET,
which is the minimum version of MacOSX that is needed to
run a piece of code.
Distutils seems to assume they're the same, but if you're
building a binary wheel for distribution, it makes sense
to set MACOSX_DEPLOYMENT_TARGET as low as possible.
Will there be a mechanism to get the actual MacOSX version
needed into the metadata, rather than the one you happen
to be building on?
--
Greg
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
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 advantage would there be in doing that? I can think of one disadvantage -- we would then need new rules to determine their priority in the search order. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 thought -- is there any need in this day and age for extensions to be limited to 3 characters? Going beyond that would give us more room to define a consistent scheme for the various combinations. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Fwd: The state of PyPI
Jim Fulton wrote: Life is short. We don't have to invent this ourselves. Are there really no existing open-source mirroring systems out there? This seems like a common enough thing that it must have been solved already. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] the usecase of continious integration based release-management (which could use more support on the ds2 side)
Mark Sienkiewicz wrote: Maybe you should go the other way: Put the version number in your source code. Make a short script that picks out the version number and constructs a tag name for the vcs. In my projects I tend to keep the definitive version number in the Makefile, and have a make target that generates a version.py file from it. This is convenient because the Makefile often needs the version number for other things like creating release tarballs. Tagging vcs commits would be another use. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] New buildout options: checksums and allow-omitted-checksums
Thomas Lotze wrote: After some further offline discussion, I'd like to suggest using MD5 as the default algorithm, though. Warnings against using md5 are mainly about cryptographic security, aren't they? For just detecting accidental corruption it should still be good enough. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] pythonv: let's also make sure the standard Python install includes an isolated python
Jim Fulton wrote: None. Barry's been using Ubuntu too long and has forgotten that Mac OS X is Unix. :) Or possibly he's thinking of the .app extension that application bundles have on MacOSX. But that's *not* the executable that gets run -- the actual executable is buried inside the Contents/MacOS directory of the bundle and usually has no extension. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] pythonv: let's also make sure the standard Python install includes an isolated python
Jim Fulton wrote: On Fri, Mar 18, 2011 at 11:18 AM, Fred Drake fdr...@acm.org wrote: On a case-senseless filesystem, distinguishing the python executable from the Python directory in the sources requires that unfortunate extension. So sad. We don't have to make it look so Windows-like, though. We could use something more cheerful such as 'python.nothisisnotthedirectory'. :-) -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] reservations about pythonv
Mark Sienkiewicz wrote: With distutils, you can't. It goes to great lengths to ensure that you can only compile a C extension with cc ... -L/some/directory -lname -- I can't find any way to make it do cc ... /some/directory/libname.so Are you sure you can't use extra_link_args for this? -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Name the software! Package quality tester.
Jim Fulton wrote: I question whether that distinction is important, but if and when it is, then we could use an adjective to clarify. Under the hood, the object we call packages today are just modules. I think the fact that we used the word package in the first place testifies that it *is* important -- otherwise we wouldn't have invented the term. The word package covers much more than just the module object that comes into being when you import it. It also implies the associated directory structure, extra import facilities and mechanisms, etc. It's not just a minor variation on the concept of a module. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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? -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 different thing. I think he has a valid point. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Design rationale for the egg format ?
Paul Moore wrote: On 14 June 2010 07:59, David Cournapeau courn...@gmail.com 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 would also seem useful to be able to keep a collection of versions of a package for different python configurations in the same directory without their names clashing. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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. Please don't take this functionality away just because of some other functionality that it doesn't provide. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 over due to some stupid bug as soon as someone tries to use it. -1 on removing this feature, +1 on fixing it. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 been asked once can hardly be called frequent by any measure. (Yes, this is pedantic -- lists of answers to questions are always useful regardless of frequency. But calling them all FAQs is technically a misnomer.) -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 standard part of Python. If a package is telling the user to install it with a non-standard installation tool, without explaining this fact and how to get the tool, then the package's documentation is lacking. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 a single version number will be sufficient. You really need to specify a more complex requirement, such as 1.0.2 = x 1.1 or x = 1.1.2 Even if you have a notion of grouping releases into series, it can still get complicated. E.g. suppose the bug was only fixed in the 1.1.3 release of the 1.1 branch -- then you need to compare with different micro release numbers in each branch. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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. Where and how do you intend the registration to happen, anyway? Would it be done by the setup.py script? In that case I don't see how it saves you anything, since you would have to first import the thing you want to register anyway. Or are you envisaging that Pyrex or whatever tool is involved would somehow patch itself into distutils when you install it? I don't like that idea much, since it smacks of the kind of monkeypatching that setuptools is reviled for. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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: from distutils import Extension, CCompile from pyrex.distutils import PyrexCompile foo_ext = Extension(foo, CCompile( PyrexCompile(foo.pyx), somelib.c)) Here Extension, CCompile and PyrexCompile are constructors for dependency graph nodes. Their responsibilities are: Extension -- takes compiled object files and libraries and links them into a Python extension. CCompile -- takes C source files and turns them into object files. PyrexCompile -- takes Pyrex source files and turns them into C source files. They would of course also take other relevant arguments such as compiler flags, search paths, etc. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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-designed and well-documented API and a clean implementation, that would be fine by me. When I say it's fundamentally broken, I'm really talking about the API. My idea of what an API for a build system should be like is more like make or scons, which slice the functionality up in a completely orthogonal direction to the way distutils does. Maybe it would be possible to plug such a system in under the existing build_ext class. I don't know. I think I would like the same philosophy applied to other areas of distutils, not just compiling extensions. Otherwise it would feel like two incompatible systems bolted together. What we need right now, I think, is some discussion about a new API, unconstrained by any considerations of backwards compatibility or reuse of existing distutils code. Once we know where we're going, then we can think about the best way to get there. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[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 on various platforms, I agree that this is important knowledge that should be preserved. But if the only way to preserve it is to keep the actual existing distutils code that implements it, we have a problem, because that IMO is the part of distutils that *most* needs improvement. It needs to be broken out of the monolithic build_ext class somehow so that the build_ext process can be extended more selectively. Evolution is better than revolution is better than nothing happening at all. I don't agree that evolution is better in and of itself than revolution. They're both means to an end -- getting something better than we have now. The problem with distutils is that evolution doesn't seem to have worked. It has just grown randomly with no clear design and ended up painting itself into a corner. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 *before* then as well. Make has been around for a lot longer, but distutils ignores everything we've learned from it. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] People want CPAN
Tarek Ziadé wrote: On Thu, Nov 12, 2009 at 12:03 AM, David Cournapeau courn...@gmail.com 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 getting all mixed up. What OOP has to do with performance in the first place ? As far as I can tell David seems to be saying that instantiating a class for every file in the system would be too much overhead. I'm not convinced about that -- make builds a dependency graph with a node for every target before it goes to work, and I think scons does something similar (although I might be wrong, I haven't looked at scons very closely yet). $CC $CFLAGS $CPPDEFINES $CPPPATH -c $SOURCE $TARGET You need to be able to control those variable content in a very fine grained manner: prepending and appending may lead to different compiler behavior It's true that the current distutils compiler classes are lacking in flexibility here -- there's an option for extra flags, for example, but it sticks them all at the end of the command. Sometimes that's wrong -- I've had trouble trying to use it for MacOSX -F arguments, for example. But that's not to say that a class couldn't be devised that allowed the required flexibility without degenerating into just a string with textual substitutions. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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, it seems to me that in this case, the basic architecture of distutils is already so full of mistakes that there just isn't an incremental way of getting to a better place, especially given the requirement of not breaking any existing setup.py scripts together with the fact that the API of distutils effectively consists of its *entire implementation*. So while complete rewrites are best avoided *if possible*, I don't think we have a choice in this case. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org 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 dependent on it. It's always been known that it's a third-party package with no official support, and one that does some pretty screwy things to boot. It's always been on the cards that it would all fall down in a crashing heap one day. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 startswith operator, I think. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] setup.cfg new format proposal
Tarek Ziadé wrote: What about 'in' ? Yes, I guess that's good enough. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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't follow that. If a conditions: line is being used to express the condition, then you can't use the name conditions for anything else anyway. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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'm against any syntax in the setup.cfg file that
resembles line noise (as the {$ $} does to my eyes).
--
Greg
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
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 future requirements. Explicit might be better than implicit here. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 on exactly what you understand by declarative, a program writtenin a functional language can be considered purely declarative, yet it can be impossible to tell what it will do without running it. I think what people mean here by static is more like can be elaborated without requiring non-trivial amounts of computation. Not just to minimise the amount of work a tool using the config file needs to do, but also to ease the task of debugging it when things don't work properly. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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] ... [requires platform=win32]: ... Then it's not so much if-then-else logic as just tagging parts of the file with conditions under which they apply. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org 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 faster. I'm wondering whether something could be gained by cacheing the results of sys.path lookups somehow between interpreter invocations. Most of the time the contents of the directories on one's PYTHONPATH don't change, so doing all this statting and directory reading every time an interpreter starts up seems rather suboptimal. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 manifests. We need a page like this concerning overall distutils reorganisation. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 like to be able to plug in a module that knows how to turn .pyx files into .c files, without requiring arcane internal knowledge and without interfering with any other extensions I might want to use at the same time. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 platforms. There's less mental gear switching involved that way when moving from one platform to another. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 .egg files that does whatever a real Windows installer would have done? Distribute it with Python and make it launch when you double-click a .egg file. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 different places on different platforms. Once you're in the icons location, the path from there to the flavour of icon you want is fixed by that spec. So the way you reference it is using something like. resource.read(module, icon, %s/48x48/apps/foo.png % theme) -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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/page.html#HDR199 although it doesn't give much idea of what it all means. There's an example of one here: http://archive.eiffel.com/doc/online/eiffel50/intro/language/invitation-15.html There's some better info here on the GNU SmartEiffel site: http://smarteiffel.loria.fr/wiki/en/index.php/ACE -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[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 mapping between class names used internally in the code and where to get them from in the environment. I think Python could do with something similar for managing version issues. Perhaps we could study how ACEs work and see if we can use any ideas from there. We could call it an AMP -- Assembly of Modules in Python. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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* a standard location within the egg. An install tool is then free to extract them out of the egg and put them somewhere else if it wants. There should also be an API for finding them (rather than assuming they're still inside the egg) so that the code that uses them can still find them if they've been moved somewhere platform-specific. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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. However, if we don't allow for such distinctions, then people who e.g. are passionate about their locale files ending up in the right place on Linux aren't going to be happy. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 code that uses them find them without platform-specific knowledge? -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 a defined way of getting just the metadata from a repository without having to download the whole package. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 bbb_extractor_script.py setup.py would create the equivalent of PKG_INFO / EGG_INFO on disk, where it could then be used to drive the new installer. It should be possible to emulate the behaviour of distutils to some extent using the new tool, so it can be invoked by making a setup() call. I don't think it could be done by statically introspecting a setup.py file, since in many cases the only way to find out what a setup.py does is to execute it. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 his own package. That makes sense to me. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 completely different implementation. Anything less would fail to fix the problems we want to fix. Given that, what would it even *mean* for the new tool to be backward compatible with distutils? The same might be happen to distutils 2 in a few years. You are going to have to plan making it more maintainable. A modular structure with an easy-to-follow implementation would certainly be part of the plan, I hope. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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_install is that is sounds like a piece of marketing propaganda. If something based on it were to become part of the standard distribution, I would hope that a more neutral name could be found. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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, if we're being fussy about terminology). -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 system won't make these sorts of problems go away, then I fully agree. But that's no reason not to have a verion management system. If you have one, then at least it provides a clear set of rules for people to try to adhere to, and helps show up when they aren't being adhered to, so that the problem can be fixed. A legitimate bug fix may break behavior that other packages depend upon while correcting the behavior for others. If it does that, then it will break other packages anyway, whether a versioning system is being used or not. So I would say it's introduced another bug which in turn needs to be fixed. The versioning system is not the cause of this and can't be blamed for it. What is needed is a Real Versioning System. A system in which a library or application consists of: 1) files 2) a dependency link map That sound like a dependency management system to me, not a version management system. They're different things, although dependency management can benefit from having a clear way of labelling versions. When the system loads the package it links in the dependent modules. Then you can get a system where: Application A imports B v 1.1 and C v 2.3 and Application D imports B v 1.4 and C v 2.6. Ummm... how is that any different from what I suggested? If in the Python context loads means uses an import statement. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 really is an ambiguity in practice -- only in the minds of those that have too much time to read standards documents. And anyway, in a computer store, you find memory for personal computers, where one byte always has 8 bits. Does it? Or... Going against the C standard seems pretty futile to me. Hmmm. So as long as I program my computer in C, it has 8 bit bytes... or at least a C implementation with 8-bit chars. But if I use a special Unicode-C with 16-bit chars, I've then got half as many bytes of memory as I had before... So I have to tell the guy in the computer shop what programming language and implementation I'm using, too! :-) Seems to me that disregarding this particular quirk of the C standard is a lesser evil than confusing everybody by changing the meaning of byte all the time. [In attempt to pull this very slightly closer to being on-topic... what does this imply for the Python bytes type? Are they always 8-bit bytes, or are they whatever size your C compiler thinks bytes are? Do the Python docs need to clarify this?] -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 version of one package A, and B another one? If they really do need different versions, this is insoluble. If they can actually use the same version because it's compatible enough, it may be necessary to make Python smart enough to notice that they're symlinks to the same file and only import it once. Or maybe something does need to be added to the language that understands version numbering, compatibility rules, etc. as I suggested in another post. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 lists how users have difficulties with MacOSX It differs from MacOSX, because MacOSX only comes with one Python installed. A lot of the problems go away if you install another one, but things aren't set up that way by default. I think this discussion is really going on because Python does not have good library-versioning support. That's probably true. I was wondering recently whether there should be some way to specify which version of a module you want when you import it, e.g. import fooble[3] which means you want a fooble with API version 3 or something compatible with it. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[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 apps expecting an earlier version, even if the new API is backwards compatible. Having said that, I just realised you can address that by putting in symlinks for the previous versions. So, I hereby propose the following convention for naming of Python packages: packagename_version where version is a number or other identifier that is changed whenever the API changes in any way. If we all follow this convention, we will be able to install and use multiple versions of a package side-by-side just as easily as we can Python versions, with no need for setuptools or any other fancy technology -- just plain standard Python the way it currently is! -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 might share files under the hood. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 concerned about cost or bandwidth use or disk space taken up, it might make sense to have apps downloaded on demand, cached, etc. But not everyone works that way. I don't, much of the time. I prefer it when downloading an app and putting it on my system is an explicit step. I know you can use 0install that way, but I do it already on my MacOSX system without needing any special tool. :-) Yes, ROX is very MacOSX-like, but I don't think it has anything to do with 0install. 0install provides one way of implementing that kind of system. But it doesn't, if by that kind of system you mean one where an app or library is just an ordinary filesystem object. A 0install app appears to be very far from ordinary. If you want to share data, it's a better way than unshared directories of files. There's nothing to stop a MacOSX user from putting an app in a publically-readable place and letting other people use it. I don't see what the big deal is there. If ROX apps included a checksum, and the system verified it before running the app, that would give you the same thing trust-wise, I think. That's an interesting idea, but how would the system find the app? The system doesn't have to find the app -- the user finds the app, using the same techniques he uses to find anything else in the filesystem he's interested in. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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/remove apps. with ROX, it seems very similar to how I imagine Mac OS applications look Yes, ROX is very MacOSX-like, but I don't think it has anything to do with 0install. But it also (plausibly) claims to allow sharing of the data that comprises an application and its dependencies between users who don't trust each other If ROX apps included a checksum, and the system verified it before running the app, that would give you the same thing trust-wise, I think. Dependency management is the part I agree is lacking in a MacOSX-like approach. Some tool for helping with that would be good to have. But I don't think it's necessary to make the components whose dependencies are being managed into anything complicated or mysterious in order to get that. They should just be files or directories that I can put into place myself, and look at to find out what I have. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 of adding more complexity to fight existing complexity, rather than removing the original complexity. In other words, it seems to be just another package manager, albeit a particulary nice-sounding one. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 trying to show Windows users what they are missing? I think the requirements for a package manager are different on different platforms. On Linux, you need to be able to cope with files scattered all over the system, and complex webs of dependencies between packages. On Windows, you need to be able to cope with scattered files and multiple applications sharing a file, but not usually with dependencies, because each application typically comes with all the files it needs (even if some of them might not get installed because they're already there for another application). On MacOSX, applications are usually completely self-contained, include all their dependencies and are not spread around, so there's really nothing for a package manager to do. What all this means for Python package management, I really don't know. Whatever is done, I'd like to see it kept as dirt-simple as possible. Ideal would be the MacOSX situation where the package is just a directory of files that you put somewhere obvious, and you can tell what it is just by looking at it, and get rid of it by dragging it to the trash -- so you don't need a package manager. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 graph, like a makefile, with each node in the graph knowing how to transform its inputs into its outputs. That would make it a lot easier to extend to accommodate new things like Pyrex. You'd just have to write a new node class that knows how to turn .pyx files into .c files, and the existing machinery would take it from there. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
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 happy to discuss. -- Greg ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
