Re: [Python-Dev] Status of packaging in 3.3
example_pkg/resource.txt
doc:
README
doc/*
doc-excluded:
doc/man
man:
doc/man
scripts:
# Directory details are stripped automatically
scripts/LAUNCH
scripts/*.{sh,bat}
# But subdirectories can be made explicit
extras/:
scripts/extras/*.{sh,bat}
- the goal of a dist.yaml syntax would be to be *explicit* and
*comprehensive*. If this gets too verbose, then the solution would be
dist.yaml generators that are less expressive, but also reduce the
necessary boilerplate.
- a typical sdist will now just be an archive consisting of:
- the project's dist.yaml file
- all files created by the source phase
- the bdist_simple format will just be an archive consisting of:
- the project's dist.yaml file
- all files created by the build phase
- the source and build run hooks and install pre and post hooks become
the way you integrate with arbitrary build systems. No fancy command
or compiler system or anything like that, you just import whatever you
need and call it with the appropriate arguments. To other tools, they
will just be opaque chunks of text, but to the build system, they're
executable pieces of Python code, just as RPM includes executable
scripts.
Cheers,
Nick.
--
Alex Clark · http://pythonpackages.com
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of packaging in 3.3
Hi, On 6/21/12 7:56 AM, Tarek Ziadé wrote: On 6/21/12 11:08 AM, Dag Sverre Seljebotn wrote: ... David Cournapeau's Bento project takes the opposite approach, everything is explicit and without any magic. http://cournape.github.com/Bento/ It had its 0.1.0 release a week ago. Please, I don't want to reopen any discussions about Bento here -- distutils2 vs. Bento discussions have been less than constructive in the past -- I just wanted to make sure everybody is aware that distutils2 isn't the only horse in this race. I don't know if there are others too? That's *exactly* the kind of approach that has made me not want to continue. People are too focused on implementations, and 'how distutils sucks' 'how setuptools sucks' etc 'I'll do better' etc Instead of having all the folks involved in packaging sit down together and try to fix the issues together by building PEPs describing what would be a common set of standards, they want to create their own tools from scratch. That will not work. But you can't tell someone or some group of folks that, and expect them to listen. Most times NIH is pejorative[1], but sometimes something positive comes out of it. And I will say here again what I think we should do imho: 1/ take all the packaging PEPs and rework them until everyone is happy (compilation sucks in distutils ? write a PEP !!!) 2/ once we have a consensus, write as many tools as you want, if they rely on the same standards = interoperability = win. But I must be naive because everytime I tried to reach people that were building their own tools to ask them to work with us on the PEPs, all I was getting was distutils sucks!' And that's the best you can do: give your opinion. I understand the frustration, but we have to let people succeed and/or fail on their own[2]. It worked with the OS packagers guys though, we have built a great data files managment system in packaging + the versions (386) Are you referring to the packaging/distutils2 or something else? Alex [1] http://en.wikipedia.org/wiki/Not_invented_here [2] http://docs.pythonpackages.com/en/latest/advanced.html#buildout-easy-install-vs-virtualenv-pip -- Dag Sverre Seljebotn ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com -- Alex Clark · http://pythonpackages.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of packaging in 3.3
Hi, On 6/21/12 1:20 PM, Tarek Ziadé wrote: On 6/21/12 6:44 PM, Chris McDonough wrote: Yes. At the very least, there will be updated development snapshots (which are what buildout uses anyway). (Official releases are in a bit of a weird holding pattern. distribute's versioning scheme leads to potential confusion: if I release e.g. 0.6.1, then it sounds like it's a lesser version than whatever distribute is up to now. OTOH, releasing a later version number than distribute implies that I'm supporting their feature enhancements, and I really don't want to add new features to 0.6... but don't have time right now to clean up all the stuff I started in the 0.7 line either, since I've been *hoping* that the work on packaging would make 0.7 unnecessary. And let's not even get started on the part where system-installed copies of distribute can prevent people from downloading or installing setuptools in the first place.) Welp, I don't want to get in the middle of that whole mess. But maybe the distribute folks would be kind enough to do a major version bump in their next release; e.g. 1.67 instead of 0.67. That said, I don't think anyone would be confused by overlapping version numbers between the two projects. Oh yeah no problem, if Philip backports all the things we've done like Py3 compat, and bless more people to maintain setuptools, we can even discontinue distribute ! If not, I think you are just being joking here -- we don't want to go back into the lock situation we've suffered for many years were PJE is the only maintainer then suddenly disappears for a year, telling us no one that is willing to maintain setuptools is able to do so. (according to him) It's known that they have been diverging for a while. Yeah the biggest difference is Py3 compat, other than that afaik I don't think any API has been removed or modified. In my opinion, distribute is the only project that should go forward since it's actively maintained and does not suffer from the bus factor. +1. I can't help but cringe when I read this (sorry, PJ Eby!): Official releases are in a bit of a weird holding pattern. due to distribute. Weren't they in a bit of a weird holding pattern before distribute? Haven't they always been in a bit of a weird holding pattern? Let's let setuptools be setuptools and distribute be distribute i.e. as long as distribute exists, I don't care at all about setuptools' release schedule (c.f. PIL/Pillow) and I like it that way :-). If one day setuptools or packaging/distutils2 comes along and fixes everything, then distribute can cease to exist. Alex -- Alex Clark · http://pythonpackages.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of packaging in 3.3
Hi, On 6/21/12 5:38 PM, Donald Stufft wrote: On Thursday, June 21, 2012 at 4:01 PM, Paul Moore wrote: End users should not need packaging tools on their machines. Sort of riffing on this idea, I cannot seem to find a specification for what a Python package actually is. FWIW according to distutils[1], a package is: a module or modules inside another module[2]. So e.g.:: foo.py is a module and: foo/__init__.py foo/foo.py is a simple package containing the following modules: import foo, foo.foo Alex [1] http://docs.python.org/distutils/introduction.html#general-python-terminology [2] And a distribution is a compressed archive of a package, in case that's not clear. Maybe the first effort should focus on this instead of arguing one implementation or another. As a packager: I should not (in general) care what tool (pip, pysetup, easy_install, buildout, whatever) is used to install my package, My package should just describe what to do to install itself. As a end user: I should not (in general) care what tool was used to create a package (setuptools, bento, distutils, whatever). My tool of choice should look at the package and preform the operations that the package says are needed for install. Ideally the package could have some basic primitives that are enough to tell the package installer tool what to do to install it, These primitives should be enough to cover the common cases (pure python modules at the very least, maybe additionally some C modules). Now as others have remarked it would be insane to attempt to do this in every case as it would involve writing a build system that is more advanced than anything else existing, so a required primitive would be something that allows calling out to a specific package decided build system (waf, make, whatever) to handle the build configuration. The eventual end goal here being to make a package from something that varies from implementation to implementation to a standardized format that any number of tools can build on top of. It would likely include some things defining where metadata MUST be defined. For instance, if metadata in setuptools was compiled down to static file, and easy_install, pip et;al used that static file to install from instead of executing setup.py, then the end user would not have required setup tools installed and instead any number of tools could have been created that utilized that data. -- Alex Clark · http://pythonpackages.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
