[Distutils] keeping a local ~/pylib directory of installed modules
Hi, I'm running on a server where I don't have root access. I've installed my own Python into ~/py-2.5.1 (with a ~/py symlink), and created my own ~/pylib directory for installing any extra packages I need. I'd like to start using Easy Install / setuptools to manage package installation, and have read the "Custom Installation Locations" --> " "Traditional" PYTHONPATH-based Installation" section of the EasyInstall manual (among other sections :). It's key that, if easy_install installs prereq's, those packages end up installed in ~/pylib (since I don't have write access to any site-packages directories). The instructions at http://peak.telecommunity.com/DevCenter/EasyInstall indicate that I should probably have a ~/.pydistutils.cfg file containing either:: [easy_install] install_dir = /home/me/pylib or else:: [install] install_lib = /home/me/pylib install_scripts = /home/me/bin So, which one of those would be suitable for my setup? It looks like an alternative to that would be using the ``--install-dir`` option to easy_install every time I run it. If using ``--install-dir``, will easy_install honor that when decending to instal dependencies as well? Note, I've already got ~/py/bin in my PATH, PYTHONPATH is being set to /home/me/pylib in my ~/.bash_profile, and it looks to me that, installing packages by-hand, the correct way for my setup is:: python setup.py install --home=/home/me/pylib So, I'm guessing that the above configurations for easy_install will get me the same thing. Any tips appreciated. Thanks. ---John ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] keeping a local ~/pylib directory of installed modules (2)
I wrote: > I'm running on a server where I don't have root access. I've installed > my own Python into ~/py-2.5.1 (with a ~/py symlink), and created my > own ~/pylib directory for installing any extra packages I need. > > I'd like to start using Easy Install / setuptools to manage package > installation, and have read the "Custom Installation Locations" --> " Ok, I see. If you've got your own local Python installed that you can write to, and that python is the first on your $PATH, everything just works with no extra options and things just get installed into your own local ``lib/python2.n/site-packages`` dir. Don't need a ~/pylib for an all-local setup like this. ---John ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Packaging Distribute
On Fri, Oct 9, 2009 at 10:34 AM, Chris Withers wrote: > Tarek Ziadé wrote: >> >> Sorry I won't run a new poll again, Distribute is the name. >> >> Besides, it's already on page #1 on google when I type 'python >> disribute' or 'distribute python' > > *shrugs* > > I will state now that I will fight tooth and nail before anything called > "distribute" gets into the stdlib that has nothing to do with distribution. Not to slash turpentine on an already painted bikeshed, but since the project's aim is to be a module distribution manager for Python, I like the name "modisty" (*mod*ule *dist*ribution manager for P*y*thon). In cases where it refuses to install a package for some reason, it could claim that "modisty forbids" such an action [snicker]. :) By the way, regarding name changes, even big projects change names every now and then (Xorg and Wireshark spring to mind) and seem to get their Google ranking back pretty quickly. Google's very good about noticing when things change. ---John ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Distribute docs at packages.python.org?
Was just looking at the Distribute docs at http://packages.python.org/distribute/index.html (nicely styled, btw). Are there any other projects at http://packages.python.org/ (note, that page actually doesn't even load)? What is the purpose of packages.python.org , and how does one get their project listed there? Btw, regarding the Distribute docs there, thanks for the Roadmap! ---John ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] current preferred way to specify dependencies? future?
Hi, What is currently the preferred way to specify (in your simple setup.py file) that your distribution depends upon a couple of other distributions? (All located at the PyPI) What is expected to be the standard way to do this in the near future? Also, is it better to specify that your distribution depends upon some other *distribution*, or some other *packages/modules*? Thanks, ---John ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] current preferred way to specify dependencies? future?
On Tue, Jan 5, 2010 at 10:44 PM, David Lyon wrote: > > Hi John, > >> What is expected to be the standard way to do this in the near future? > > PEP-345 says: > > > Requires-Dist: pywin32 (>1.0); sys.platform == 'win32' > > Obsoletes-Dist: pywin31; sys.platform == 'win32' > > Requires-Dist: foo (1,!=1.3); os.machine == 'i386' > > Requires-Dist: bar; python_version == '2.4' or python_version == '2.5' > > Requires-External: libxslt; 'linux' in sys.platform > > To me that's really confusing. I'm a bit confused myself... PEP-345 says it "describes a mechanism for adding metadata to Python packages", but I think they really mean "distributions" (the things available at the PyPI). Also, it looks like pep345 describes what fields can go into a PKG-INFO file, but not how you get them in there. AFAIK, I'm not supposed to write my own PKG-INFO file -- setup.py does it for me. What I'm really asking about here is, what args go in the `setup()` call in the `setup.py` file? If my FooBar-0.1.0 distribution depends upon packages and modules in CoolStuff-2.0.0 and ReallyNeatStuff-1.5.5, what's the current best way to say so, and what's going to be the standard going forward? Thanks, ---John ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] current preferred way to specify dependencies? future?
On Wed, Jan 6, 2010 at 11:07 AM, Carl Meyer wrote:
>
> {snip} Following the principle of least surprise I would assume
> they would be requires_dist, provides_dist, etc, and would take lists of
> strings, in the same format as in the PEP (name followed by version spec
> in parenths).
> {snip}
>
>> If my FooBar-0.1.0 distribution depends upon packages and modules in
>> CoolStuff-2.0.0 and ReallyNeatStuff-1.5.5, what's the current best way
>> to say so, and what's going to be the standard going forward?
>
> The current most-often-used way to say so is to the setuptools-specific
> argument install_requires=['CoolStuff==2.0.0', 'ReallyNeatStuff==1.5.5']
> (though that's being perhaps a bit more precise with the version
> specifiers than you'd really want to be). Obviously that's only
> supported if you use setuptools. The standard going forward will
> hopefully be PEP 345.
Great. Thanks. Then, I'd like to put:
requires_dist=['CoolStuff>=2.0.0', 'ReallyNeatStuff>=1.5.5'],
into my `setup()` call. Currenlty, I've got this at the top of my `setup.py`:
from distutils.core import setup
What do I need to change that to, in order for (A) the `requires_dist`
argument to work, and (B) in order to use Distribute rather than
setuptools?
Thanks,
---John
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [RFC] Python 2.7 Distutils extra features
On Wed, Jan 6, 2010 at 12:13 PM, Tarek Ziadé wrote: > > - a new option for sdist called 'extra_files', that will allow to list > extra files to be included in the distribution. these > files will not be installed by 'install', just be part of the distribution. > > Any comments ? Would this replace the need for MANIFEST.in? If not, what would MANIFEST.in still be used for? ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] packaging terminology confusion
On Thu, Jan 7, 2010 at 7:03 AM, Tarek Ziadé wrote: > On Thu, Jan 7, 2010 at 12:48 PM, Eric Smith wrote: > [..] >> >> We should use the terminology as defined in >> http://docs.python.org/distutils/introduction.html#distutils-specific-terminology >> >> So technically it's a "module distribution" we're talking about. > > Well, I wonder if we shouln't use the term "distribution" instead > here. the "module" word is quite fuzzy to describe a distribution that > might contain modules, data files, and/or packages. I agree, since you can make a distribution with nothing in it but scripts (no modules or packages). Nice way to distribute "python programs" too, IMO. Incidentally, the Perl folk technically refer to the things they upload to the CPAN as "distributions" as well. Though, they often call them "modules" in casual conversation/writing ... possibly because it's 2 syllables shorter and/or easier to type. :) The only inconsistency, I think, is that operating systems like Debian refer to their software distributions as "packages" (as in, a packaged up piece of software that you can download and install). "Packages" is a great name for them -- too bad it's already being used in Python. ---John ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] packaging terminology confusion
On Thu, Jan 7, 2010 at 9:56 AM, Tarek Ziadé wrote: > On Thu, Jan 7, 2010 at 3:52 PM, John Gabriele wrote: >> The only inconsistency, I think, is that operating systems like Debian >> refer to their software distributions as "packages" (as in, a packaged >> up piece of software that you can download and install). "Packages" is >> a great name for them -- too bad it's already being used in Python. > > I believe that's basically where the confusion comes from. Whoops. Just noticed that the front page of the PyPI says: > "There are currently 8614 packages here." (is that 8614 packages or 8614 distributions?) and, > "To submit a package use "python setup.py upload" and to use a package from > this index either "pip install package" or download, unpack and "python > setup.py install" it." and > "# Browse the tree of packages # Submit package information" ---John ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Catalog-sig] packaging terminology confusion
On Thu, Jan 7, 2010 at 5:22 PM, Tarek Ziadé wrote: > On Thu, Jan 7, 2010 at 11:12 PM, M.-A. Lemburg wrote: > [..] >> I usually refer to the latter as 'Python package' and the former >> as 'package'. >> >> What you download is a 'distribution file' which could be an exe, >> a tarball, an egg, etc. There are many forms such a package >> distribution can take and just as many ways to install them. > > That would be a "release" instead imho. (I like Tres' definitions for that) > e.g. a "release" comes in several "distributions" : an egg, a source > dist, a binary dist, etc. > >> >> Once installed a 'package' usually creates a single 'Python package' >> (at top-level or some lower level). > > That's not always the case. Many projects have also scripts, and /or > top level modules in site-packages. I've got a few brief observations, and also a suggestion. 1. In english, the word "package" can mean an aggregation of features, as in, "We got married, stayed at a hotel, and got the honeymoon package. Heart-shaped bed, champagne, and chocolate-covered strawberries in the fridge!". So, it's a great name for something that aggregates things, like modules. 2. Also, in english, the word "package" can also mean a nice sealed box that you send out via or receive from the postal mail. So, it's a great name for those tgz things that you upload to or download from the PyPI. 3. People don't like calling those MyProject-1.0.2.tgz thingies "distributions". They keep calling them packages, and when you correct them, they say, "[sigh], fine. [eyes roll] 'distribution'." 4. A "project" is just a general term for a named thing that people work on. "I'm working on my Isengard Reforestation project! I think it's going to be very successful! I'm keeping it in my `~/dev/projects/IsengardReforestation` dir." But I don't think `IsengardReforestation-1.0.2.tgz` would be referred to as a "project" per se, nor a "project file". A "project file" is one of those things that an IDE gives you to keep track of which files belong in the project, how to build it, and so on---so I wouldn't call it that either. 5. There are already a bunch of tools that refer to those PyPI tgz things as distributions (for example, Distutils). 6. The word "distribution" is long to type and long to say. And also, when I think of a Python distribution, I imagine the `Python-2.6.4.tgz` file you download from python.org. *That's* a Python distribution (along with the previous Python releases). Also, ActiveState has a Python distribution too. So, here's a suggestion: just call both things (packages and distributions) "packages", but then agree to fully qualify the names when you need to avoid ambiguity, for example: "I just built a distribution-package (or "dist-package" for short) and included numerous module-packages in it." * If you mean the kind of package holds modules, and the meaning isn't clear from the context, say "module-package" (think "honeymoon package") * If you mean the kind of package hosted at the PyPI, and the meaning isn't clear from the context, say "distribution-package" or "dist-package" (think parcel/postal package) This way, * The PyPI now becomes the "Python dist-package index", or just "Python Package Index (PyPI)" for short. :) * Distutils is now the "distribution-package utilities" or just "dist utilities" for short. :) * We can slowly fully-qualify the name "distribution" in the docs, gradually replacing it with "distribution-package" or "dist-package" (when it's referring to dist-packages) and it won't be much of a shock to the system. How's that sound? ---John ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Catalog-sig] packaging terminology confusion
On Thu, Jan 7, 2010 at 10:58 PM, "Martin v. Löwis" wrote: >> How's that sound? > > I read this as a -1 for changing PyPI to use "project". Well, I'd say not -1, nor +1. I think either name for the PyPI is ok. I was trying to address the larger issue of confusion of terminology. I think that no matter what you call the site, in common use users will still catch themselves saying "get a package from the PyPI", rather than "get a project from the PyPI". I mean, even some experts here accidentally refer to distributions as packages. ---John ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Catalog-sig] packaging terminology confusion
On Thu, Jan 7, 2010 at 10:43 PM, John Gabriele wrote: > > So, here's a suggestion: just call both things (packages and > distributions) "packages", but then agree to fully qualify the names > when you need to avoid ambiguity, for example: "I just built a > distribution-package (or "dist-package" for short) and included > numerous module-packages in it." > > * If you mean the kind of package holds modules, and the meaning isn't > clear from the context, say "module-package" (think "honeymoon > package") Whoops. Looking back through this thread, that last line should probably read: """ ... say, as Brad A. suggested above, "module-package" ... """ ---John ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Catalog-sig] packaging terminology confusion
On Fri, Jan 8, 2010 at 1:50 AM, Glyph Lefkowitz wrote:
> On Jan 7, 2010, at 10:43 PM, John Gabriele wrote:
>
> 3. People don't like calling those MyProject-1.0.2.tgz thingies
> "distributions". They keep calling them packages, and when you correct
> them, they say, "[sigh], fine. [eyes roll] 'distribution'."
>
> This is not my experience of the term. It's more that most people *still*
> don't know what the term "distribution" means in this context, unless
> they've extensively read the distutils documentation. Or that they're
> talking about Python "distributions" at the same time as what Linux
> distributions are doing with them, and are trying to avoid being ambiguous.
Hm. Well, it's possible I'm reading too much into online commentary
while wearing my cheese-colored glasses.
> It sure would be nice if we could use a made-up word like "eggs" to refer to
> these things. Too bad that's taken too :-\.
If there's a desire to replace the word "distribution" (meaning, the
tgz's at the PyPI) in the technical docs to increase clarity, then
your suggestion of "parcel" is certainly good. Another might be
"bundle" (though, that one's used on Mac OS X in connection with
shared libs, I think).
I like saying "Python distribution" to mean the big archive file you
download to install Python on your system.
Of course, the PyPI could be renamed "Python Project Index" regardless
of the technical name used for Fred's GBOFs. :)
I also think that the instructions on the front page of the PyPI could
say "usage: `pip install ProjectName` or `python setup.py install
ProjectName`" and it would be clear, again, regardless of what the
technical name of GBOFs are.
Re. Barry's recent comment:
>
> I wish there was a humorous, ironic name for the service that is evocative of
> {snip}
Could always come up with such a name, and still use "The Python
Project Index" as the main *subtitle*.
---John
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Catalog-sig] packaging terminology confusion
On Sat, Jan 9, 2010 at 2:48 PM, Lennart Regebro wrote: > On Sat, Jan 9, 2010 at 20:17, Suno Ano wrote: > >> - *package* means a Python package, (directory intended to be on >> sys.path, with an __init__.py. We *never* mean a distributable >> or installable archive, except when “impedance matching” with >> folks who think in terms of operating system parcels. >> >> - *parcel* is such a distributable / installable archive: >> either in source form (an ’sdist’), or one of the binary >> forms (egg., etc.). Any parcel may contain multiple >> packages (or even no packages, in the case of standalone >> scripts). >> >> - *project* is the process / community which produces releases of >> a given set of software, identified by a name unique within >> PyPI’s namespace. PyPI manages metadata about projects (names, >> owners) and their releases. Every real project has at least >> one release. >> >> - *release* is a set of one or more parcels of a project, >> each sharing the same version. Some PyPI metadata is specific >> to a release, rather than a project. Every release has at >> least one parcel. >> >> - *installer* is an OS specific piece of software provides by >> some project which usually installs a Python interpreter and >> other general software in order to have some Python >> application installed from scratch. > > Yes. Again, exactly how I use the words already. This is the same for > all intents and purposes as Tareks proposal, this is how the words are > being used already in practice. I would also add the common use of the term "distribution" to that glossary as well. At http://python.org/download/ , that big software archive that you download, unpack, and install---giving you a Python installed on your system---is referred to as a "distribution". Ex., "the python.org Python distribution", "the ActiveState Python distribution", etc. Enthought calls theirs a distribution as well: http://enthought.com/products/epd.php Incidentally, Perl calls theirs distributions too: http://www.cpan.org/ (source code distribution available here http://www.cpan.org/src/README.html ). Ruby calls theirs distributions as well http://www.ruby-lang.org/en/downloads/ . ---John ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Catalog-sig] packaging terminology confusion
On Sun, Jan 10, 2010 at 6:53 AM, Tarek Ziadé wrote: > On Sun, Jan 10, 2010 at 12:40 PM, Ben Finney > wrote: > >> At this point, people are just going to keep calling this entity a >> “package”, consistent with the majority of other languages and systems >> out there. > > Who is "people". AFAIK, most Python developers use the word "package" > for "python package" > and when they use the word "package" for "distribution", they will > stop doing it if they are told > that the proper word is "distribution" imho. Well, I notice that the entire [packaging chapter of diveintopython3](http://diveintopython3.org/packaging.html) refers to distributions as "packages". And it's *very* common for new users to be sent to diveintopython/diveintopython3 when learning the language. ---John ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Catalog-sig] packaging terminology confusion
On Mon, Jan 11, 2010 at 6:53 AM, Lennart Regebro wrote: > On Mon, Jan 11, 2010 at 12:33, Ben Finney wrote: >> Lennart Regebro writes: >> >>> I said that it's not a big problem because in most cases the >>> terminology mixup does not result in any practical confusion. And I >>> stand by that. >> >> So we're back to a tautology: where the terminology doesn't cause >> confusion, it doesn't cause confusion. True, but not terribly useful. > > Except that this is not what I said. Lennart, like you said, there's not much confusion for the majority of cases where the distribution-package (distribution) contains only one module-package. That is, if my CheeseWheel dist-package contains exactly one module-package (named cheese_wheel), then there's pretty much no confusion. But, of course, there are cases when it's more complicated than that, and (IMO) using one term for both will lead to confusion. ---John ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Catalog-sig] packaging terminology confusion
On Mon, Jan 11, 2010 at 9:19 AM, Barry Warsaw wrote: > On Jan 10, 2010, at 7:57 PM, David Lyon wrote: > >> As a regular developer, I'd call for a "L'Oeuf incredible". Excuse my bad >> french. A new egg to replace all the bad old eggs. >> >> We need more simplicity in packaging in python.. >> >> "eggs" are cool. They're simple. They're what users want. They're what >> pypi needs. > > +1 > Do you mean, change the general name of these packaged up things from "distributions" to "eggs"? So, we'd generically refer to, say, "CheesyComestible-1.2.3.tgz" as an egg? Interesting. What term would you use to refer specifically to a ".egg" file? ---John ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [Catalog-sig] packaging terminology confusion
On Tue, Jan 12, 2010 at 8:14 PM, Zooko Wilcox-O'Hearn wrote: > On Saturday, 2010-01-09, at 11:47 , Brad Allen wrote: > >> Now I understand that your 'project' concept probably corresponds to an >> entry in PyPI which is associated with multiple releases > > Yep. Or actually the "project" is the thing that a few hackers like to > spend their time on. It is the thing that evolves over time, endures forks > and personnel changes, etc. The page on PyPI is best understood as being > the web page on PyPI which is here to inform you about the state of the > project. > > I tell people at hacker meetups that I work on the Tahoe-LAFS project. They > nod their heads. I'm going to continue saying that, and they are going to > continue nodding their heads, regardless of what we on this mailing list > decide. > >> When you have a release ready, what do you do with it? You 'package' it, >> of course. You don't 'project' it, and you don't 'parcel' it. What is the >> result of the 'packaging' activity? It's a 'package' of course. > > Bingo! And, this is true regardless of whether you're working on a project > written in Python or in another language or in a combination of languages. > >> Maybe it's just wrong to call the __init__.py directories 'packages', >> because they are really just a piece of what is getting packaged. > > Bingo! A "package" is something that you deliver to someone else and they > use it. You don't deliver __init__.py directories to people. __init__.py > directories are not packages. > +1 If it were possible to rename "package" (the __init__.py kind), I might suggest going with "battery", as in, "a whole battery of modules". ( http://dictionary.reference.com/browse/battery ) Perhaps folks who run projects that distribute large numbers of related packages/batteries could somehow distribute them together as ... oh, I dunno, ... a battery pack. :) Also, fits well with "batteries included" motto. :) http://python.org/images/batteries-included.jpg ---John ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
