Re: [Distutils] Non English Speaking Users of PyPI - I need Help!

Hi Donald, Thanks for the pointer to l20n, I hadn't seen it before; as a standard data format for translations it certainly looks much more flexible and nicer to use than gettext! I'm curious about this, though: On 01/26/2016 12:10 PM, Donald Stufft wrote: > Now, all of the above could be

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 10/09/2015 12:28 PM, Oscar Benjamin wrote: > Why would it need dynamic metadata for the windows matplotlib wheel to > have different metadata from the OSX matplotlib wheel? The platform > Windows/OSX is static and each wheel declares its own dependencies > statically but differently. Am I

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 10/09/2015 12:44 PM, Oscar Benjamin wrote: > > On Fri, 9 Oct 2015 19:35 Carl Meyer <c...@oddbird.net > <mailto:c...@oddbird.net>> wrote: > > On 10/09/2015 12:28 PM, Oscar Benjamin wrote: > > Why would it need dynamic metadata for the windows matplotli

Re: [Distutils] Towards a simple and standard sdist format that isn't intertwined with distutils

On 10/09/2015 11:18 AM, Paul Moore wrote: > On 9 October 2015 at 18:04, Chris Barker wrote: >> 1) what in the world is a "source wheel"? And how is it different than an >> sdist (other than maybe in a different file format. > > A "source wheel" is the proposed name for a

Re: [Distutils] Where should I put tests when packaging python modules?

On 10/06/2015 04:04 PM, Antoine Pitrou wrote: [snip] > ...How are tests supposed to be a problem here, while they > usually have so few dependencies of their own? > >> If you have to bend over backwards (to install the test dependencies) > > While some packages may have non-trivial test

Re: [Distutils] How to implement ‘setup.py’ functionality that itself needs third-party distributions

On 01/20/2015 07:28 PM, Ben Finney wrote: What I need is a way to express “ensure Docutils is installed before continuing with other Setuptools actions” in ‘setup.py’. I don't know of a neat way to tell Setuptools that. That is the precise purpose of the `setup_requires` kwarg.

Re: [Distutils] Python module for use in ‘setup.py’ but not to install

On 01/19/2015 01:23 AM, Ben Finney wrote: [snip] My understanding, based on an answer received elsewhere [0], is that omitting the file from ‘setup.py’ but adding it to ‘MANIFEST.in’ causes it to be included in the sdist but omitted from install targets. [0]

Re: [Distutils] Python module for use in ‘setup.py’ but not to install

On 01/19/2015 12:39 AM, Nick Coghlan wrote: On 19 January 2015 at 11:59, Ben Finney ben+pyt...@benfinney.id.au wrote: Nick Coghlan ncogh...@gmail.com writes: I actually misunderstood your question. If you're just after the ability to say I want to include this file in the sdist, but not in

Re: [Distutils] some questions about PEP470

Hi Holger, On 10/11/2014 12:31 AM, holger krekel wrote: I understand that as a fairly generic security statement. But I was trying to rather ask about use cases and scenarios where precisely the --extra-index-url option is useful and to be recommended. I'd be grateful if Nick or you could

Re: [Distutils] advice re: packaging tasks

Hi Chris, On 09/30/2014 05:44 PM, Chris Jerdonek wrote: 2) Secondly, like many, my README files are in markdown, so I hacked a command in my setup.py to use Pandoc to convert README.md to a .rst file for use as the long_description argument to setup(). I also check in the resulting file for

Re: [Distutils] Immutable Files on PyPI

On 09/30/2014 08:41 AM, Nick Coghlan wrote: Why is your setup.py sdist including autogenerated content? It shouldn't be doing that. Don't almost all sdists? At the very least egg-info is autogenerated, MANIFEST usually is too. Carl ___ Distutils-SIG

Re: [Distutils] PEP470, backward compat is a ...

On 05/16/2014 12:10 PM, Donald Stufft wrote: 2. Add a deprecation path for --allow-unverified; can describe it in general terms as the PEP 438 installer flag allowing installation of unverified external packages if you don't want to be pip-specific. Currently PEP 470 has no mention of this,

Re: [Distutils] PEP470, backward compat is a ...

On 05/16/2014 02:15 PM, Donald Stufft wrote: I guess the key thing I don't understand yet is, why would we assume that any package that hasn't already switched to verified-external-links since PEP 438, given a one-year window so far to do so, is any more likely to populate this new

Re: [Distutils] PEP470, backward compat is a ...

On 05/16/2014 04:00 PM, Paul Moore wrote: On 16 May 2014 20:27, Carl Meyer c...@oddbird.net wrote: Or, thirdly, Paul's proposal could solve this, if PyPI automatically generated an external legacy index for any packages that haven't generated their own external index URL by a certain date

Re: [Distutils] setup.py should use if __name__ == '__main__', right?

On 04/06/2014 09:04 PM, Asheesh Laroia wrote: Hi nice distutils/PyPA people, I had a question that probably is worth showing up in the archives. Namely: It seems to me like bizarre bad form for the setup.py file to execute what amounts to a main() function at import time. I presume this

Re: [Distutils] restart-in-venv (was: PEX at Twitter (re: PEX - Twitter's multi-platform executable archive format for Python))

Hi Vinay, On 02/01/2014 09:25 AM, Vinay Sajip wrote: On Sat, 1/2/14, Donald Stufft don...@stufft.io wrote: So perhaps it isn't that pip is lacking a useful feature, it's that pip tried it, as you did with distil, and due to pip's much larger user base it got a much more thorough real world

Re: [Distutils] Python Packaging User Guide has moved

Could we stop cross-posting this thread to both pypa-dev and distutils-sig? Seems like it belongs on pypa-dev to me, but I don't really care so long as it isn't cross-posted to both :-) Carl ___ Distutils-SIG maillist - Distutils-SIG@python.org

Re: [Distutils] pip uninstall and pip's lack of support for installing eggs

On 11/15/2013 02:16 PM, Marcus Smith wrote: Under the covers, pip uses setup.py install --record (which requires also using --single-version-externally-managed) in order to create an install log, that get's used for uninstalls. And due to using `--single-version-externally-managed`, the

Re: [Distutils] pip uninstall and pip's lack of support for installing eggs

On 11/15/2013 03:14 PM, Marcus Smith wrote: ok, looking at this more, pip uninstall wasn't added until v0.6, so probably it just used `--record` for it's log as a side-effect of the previous decision to use `--single-version-externally-managed`. Pip's use of --record to record a list of

Re: [Distutils] Comments on PEP 426

On 09/07/2013 11:33 AM, Vinay Sajip wrote: Carl Meyer carl at oddbird.net writes: Sidenote, and already mentioned by MAL upthread, but --record is a distutils feature, not a setuptools feature, so this is not the reason pip forces setuptools. I think the actual reason is so that pip can

Re: [Distutils] Comments on PEP 426

On 09/04/2013 07:27 AM, Nick Coghlan wrote: I was under the impression pip *already* forced the use of setuptools (to ensure --record is available) Sidenote, and already mentioned by MAL upthread, but --record is a distutils feature, not a setuptools feature, so this is not the reason pip

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

On 08/21/2013 03:29 AM, Donald Stufft wrote: Can you send me a list (or post them here) of what issues you've hit? The biggest one i'm aware of is the scripts problem which is a fundamental problem with the 1.0 Wheel (or rather that any library with console entry points cannot be universal).

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

On 08/21/2013 10:32 AM, Daniel Holth wrote: 2) Wheel's decision to follow distutils' documentation rather than distutils' behavior when it comes to the location for installing data_files with relative paths; see

Re: [Distutils] pip - installation of the latest stable version of package

On 07/21/2013 01:38 PM, Piotr Dobrogost wrote: Does pip support installation of the latest _stable_ version of package (for all versions which adhere to PEP386)? Related - Do not upload dev releases at PyPI by Tarek Ziadé http://ziade.org/2011/02/15/do-not-upload-dev-releases-at-pypi/at

Re: [Distutils] Q about best practices now (or near future)

On 07/22/2013 06:31 AM, Daniel Holth wrote: Yes, extras are *only* a way to create aliases for a set of dependencies. They are not recorded as installed. It should make no difference whether you install ipython[notebook], look up the dependencies for the ipython notebook and install them

Re: [Distutils] PEP 439 and pip bootstrap updated

On 07/11/2013 03:48 PM, Nick Coghlan wrote: I was thinking about that, and I'm wondering if the most sensible option may be to claim the getpip name on PyPI for ourselves and then do the following: 1. Provide getpip in the standard library for 3.4+ (and perhaps in a 2.7.x release) 2.

Re: [Distutils] PEP 439 and pip bootstrap updated

Hi Richard, On 07/09/2013 09:47 PM, Richard Jones wrote: On 10 July 2013 13:20, Donald Stufft don...@stufft.io wrote: On Jul 9, 2013, at 11:16 PM, Richard Jones r1chardj0...@gmail.com wrote: Firstly, I've just made some additional changes to PEP 439 to include: - installing virtualenv as

Re: [Distutils] option #1 plus download_url scraping

On 06/04/2013 04:30 PM, Donald Stufft wrote: I'm interested in the use case. How are generating a release without running setup.py sdist? I think you misunderstood (the way Barry described it wasn't completely clear). If I'm reading it correctly, I don't want to have to change setup.py every

Re: [Distutils] option #1 plus download_url scraping

Hi Barry, On 06/04/2013 04:16 PM, Barry Warsaw wrote: Like many of you, I got Donald's message about the changes to URLs for Cheeseshop packages. My question is about the three options; I think I want a middle ground, but I'm interested to see why you will discourage me from that wink.

Re: [Distutils] distil 0.1.1 released

Hi Nick On 05/03/2013 12:14 PM, Nick Coghlan wrote: I would also be relatively happy for pip to refuse the temptation to guess if run globally and require an explicit --user or --system whenever it is run outside a virtual environment. However, I think it's better to make the typical pip

Re: [Distutils] Towards a bandersnatch release - updates, PIP, contacting mirror owners

Hello Christian, On 04/08/2013 09:09 AM, Christian Theune wrote: As I have not used pip seriously before, I'm wondering how people document service setups for pip users that are repeatable, i.e. where all dependency versions will be fixed. I think the verdict on fixing versions in setup.py

Re: [Distutils] The pypa account on BitBucket

FWIW I think if pip and virtualenv are being elevated to a new level of official, I have no problem with the pypa name being used as the umbrella for the next few years' improve python packaging efforts. I know I've talked to some people who don't follow packaging closely who thought this was

Re: [Distutils] Setuptools-Distribute merge announcement

On 03/13/2013 06:54 PM, PJ Eby wrote: Jason Coombs (head of the Distribute project) and I are working on merging the bulk of the improvements distribute made into the setuptools code base. He has volunteered to take over maintenance of setuptools, and I welcome his assistance. This merge is

Re: [Distutils] pip/easy_install mercurial in virtualenv on Python 3.3

Hi Christian, On 02/25/2013 05:27 AM, Christian Tismer wrote: Some further analysis of the problem: Mercurial is (and should be) installed system-wide. The 'hg' command (at least my homebrew install) uses the normal shebang line #!/usr/bin/env python When using virtualenv and

Re: [Distutils] pip/easy_install mercurial in virtualenv on Python 3.3

Hi Christian, On 02/25/2013 07:48 AM, Christian Tismer wrote: After looking into pip help install, I tried to run (venv) $ pip install mercurial --install-option=--c2to3 Yes, this should be the correct way to pass an option directly to Mercurial's setup.py. Now the crazy effect is:

Re: [Distutils] pip/easy_install mercurial in virtualenv on Python 3.3

On 02/25/2013 10:31 AM, Christian Tismer wrote: Actually, I would love to have both python2 and python3 in the same virtualenv, for testing purposes, distinguishing the versions by using the different interpreter, only. But installing both versions after another messes things up very much and

Re: [Distutils] [Python-Dev] [Python-checkins] peps: PEP 426: replace implied 'version starts with' with new ~= operator

On 02/23/2013 08:08 PM, Nick Coghlan wrote: On Sun, Feb 24, 2013 at 4:43 AM, Daniel Holth dho...@gmail.com wrote: There simply must be a way to spell equals that means equals. It will be used when that so-called security release broke my application that integrates said library in a way that

Re: [Distutils] (How) do setuptools/distribute/pip handle circular dependencies?

Hi Vinay, On 11/09/2012 03:56 PM, Vinay Sajip wrote: Vinay Sajip vinay_sajip at yahoo.co.uk writes: So, according to the declarations, each package depends on the other. Can setuptools / distribute deal with this sort of situation? If so, how does that work? My question also applies to

Re: [Distutils] Proposal: drop md5 for sha256

On 07/04/2012 12:51 PM, Daniel Holth wrote: Pip install lxml - 1m 51s Pip install -f file:///temp/wheels lxml - 27s I am not sure why pip is so slow for me. The lxml binary package install could take as little as 0.1 seconds if pip wasn't consulting the net. If you don't want pip to consult

Re: [Distutils] Requires-Dist: unittest2; 'test' in extras

On 05/31/2012 09:04 AM, PJ Eby wrote: Since I haven't used pysetup yet, I couldn't really say. I can say that some people have mentioned that they find setuptools' extras mechanism to be confusing, unnecessary, or a tool in search of a usecase. I'm not terribly attached to them, but I prefer

Re: [Distutils] command hooks...

On 05/29/2012 08:19 AM, PJ Eby wrote: On Tue, May 29, 2012 at 10:20 AM, Erik Bray erik.m.b...@gmail.com mailto:erik.m.b...@gmail.com wrote: This particular solution works for me. But the point is that it can be done pretty easily. However, the lack of a setup_requires-like

Re: [Distutils] command hooks...

On 05/29/2012 02:01 PM, PJ Eby wrote: On Tue, May 29, 2012 at 1:24 PM, Carl Meyer c...@oddbird.net wrote: On 05/29/2012 08:19 AM, PJ Eby wrote: Right, and I don't think distutils2 can really add setup_requires without blessing a package manager. I'm confused

Re: [Distutils] pip on windows: life without eggs ok?

Hi Chris, On 04/15/2012 09:07 PM, Chris Lambacher wrote: If I were telling a new Windows Python user what to do to get started, I would tell them to use easy_install because easy_install will pick up both installers and binary eggs and do the right thing with those and virtualenvs. Agreed.

Re: [Distutils] pip on windows: life without eggs ok?

Hi Reinout, On 04/16/2012 04:31 AM, Reinout van Rees wrote: Thanks Chris and Matthew for the info! Especially about the upcoming no-site-packages default. --no-site-packages has been the default since the release of virtualenv 1.7, which happened on Nov 30, 2011. Carl signature.asc

Re: [Distutils] pip on windows: life without eggs ok?

On 04/16/2012 03:56 PM, Paul Moore wrote: On 16 April 2012 20:08, Carl Meyer c...@oddbird.net wrote: Support for installing binary packages on Windows has been a patches welcome situation for as long as I've used pip (3-4 years?) - all that's lacking is someone motivated to provide a good

Re: [Distutils] using pip to install an specific, older version

Hi Chris, On 04/04/2012 02:10 PM, Chris Jerdonek wrote: On Mon, Apr 2, 2012 at 12:08 PM, Carl Meyer c...@oddbird.net wrote: Also, you may want to be aware that the -E flag is deprecated and is already removed in the latest pip release (1.1) because it does not handle isolated virtualenvs

Re: [Distutils] Spec for the egg-info format

On 03/07/2012 09:07 PM, PJ Eby wrote: On Mon, Mar 5, 2012 at 4:47 PM, Paul Moore p.f.mo...@gmail.com mailto:p.f.mo...@gmail.com wrote: Is there a good spec of the egg-info (directory) format anywhere? [snip] - Should filenames in installed-files.txt be absolute or relative (and

Re: [Distutils] RFC: Binary Distribution Format for distutils2/packaging

On 03/14/2012 09:33 AM, PJ Eby wrote: Again, this raises the question: is .pbd a load-and-go format for distributing and *running* Python code, or is it just a way to bundle compiled extensions along with source code to simplify installation? I worry that some folks in the conversation may

Re: [Distutils] Support for multi-index ?

Hi Mathieu. To complexify Chris' unambiguous YES! slightly: On 05/11/2011 08:26 AM, Mathieu Leduc-Hamel wrote: Great, thanks Chris and Carl, but does it mean i can use the find-links in the same spirit of the index option ? In the same spirit, certainly. But the details of how you use it will

Re: [Distutils] Support for multi-index ?

Hi Chris, On 05/11/2011 11:17 AM, Chris Withers wrote: On 11/05/2011 17:02, Carl Meyer wrote: Depends what you mean by our internal pypi instance. If you already have a running instance of some software that emulates PyPI, including the specific layout of PyPI's project/version URLs

Re: [Distutils] Support for multi-index ?

On 05/09/2011 02:09 PM, Mathieu Leduc-Hamel wrote: yes but with find-links i think you are forced to defined a specific link which point directly to the package, and the index option is where you can specify another pypi index. am i right ? Depends what you mean by point directly to the

Re: [Distutils] virtualenv3

Hi Barry, On 05/06/2011 03:49 PM, Barry Warsaw wrote: So I have some more information on this. Debian Wheezy has 1.6 now, but -p python3 still did not work. Here is the bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625784 The problem occurs when virtualenv.py

Re: [Distutils] virtualenv3

On 05/06/2011 04:43 PM, Carl Meyer wrote: I don't quite understand this. On my Ubuntu system, with either Ubuntu's Python 2.6 or my compiled 3.2, sys.path[0] appears to always be the empty string, never the actual full path of the script's directory. How is it ever == '/usr/share/pyshared

Re: [Distutils] virtualenv3

Hi Barry, On 05/04/2011 11:01 AM, Barry Warsaw wrote: What's the current status of virtualenv3? When I search the Cheeseshop, I get two hits: http://pypi.python.org/pypi?%3Aaction=searchterm=virtualenv3submit=search It looks like Holger's virtualenv5 is a temporary fork of Brandon's

Re: [Distutils] dependencies, pip and non-PyPI-hosted packages

On 04/23/2011 02:00 PM, P.J. Eby wrote: At 04:54 PM 4/22/2011 -0500, Carl Meyer wrote: No, it is calling the distribute setup. If you look at how your package is installed, you'll find it in an egg - that's a sure sign of setuptools/distribute. It's just that python setup.py install does

Re: [Distutils] dependencies, pip and non-PyPI-hosted packages

Hi Ernesto, On 04/22/2011 11:34 AM, Ernesto Posse wrote: Thanks. I have another question. Now that I'm using distribute, pip handles the requirements correctly, but if I install with: python setup.py install the dependencies are not installed. This is a bit perplexing. This is just how

Re: [Distutils] dependencies, pip and non-PyPI-hosted packages

On 04/22/2011 06:09 PM, Ernesto Posse wrote: Hmm... OK, I guess I assumed that distribute was extending the standard distutils install command to install dependencies, rather than pip being responsible. So essentially to take advantage of distribute one must use pip? It extends distutils to

Re: [Distutils] Need help with a usecase

Hi Reinout, On 04/19/2011 02:46 AM, Reinout van Rees wrote: The one thing that, to me, still is a big advantage of buildout over virtualenv in cases like this: you can just run the scripts in bin/* as-is. You do not need to activate the virtualenv beforehand. There are good reasons why one

Re: [Distutils] dependencies, pip and non-PyPI-hosted packages

Hi Ernesto, On 04/19/2011 12:42 PM, Ernesto Posse wrote: Hi I have a couple of packages that I don't want to upload to PyPI just yet but they are hosted some other place, and one (project2) depends on the other (project1). I've packaged them using the standard distutils setup. For

Re: [Distutils] pythonv, take two

On 03/31/2011 04:12 AM, Vinay Sajip wrote: Carl Meyer carl at oddbird.net writes: The logical conclusion of that approach, if you want full compatibility with third-party code, is to just copy the entire Python installation to the new location. We do want that compatibility, don't we

Re: [Distutils] pythonv, take two

On 03/31/2011 09:21 AM, Vinay Sajip wrote: Vinay Sajip vinay_sajip at yahoo.co.uk writes: I think the problem is occurring because there's incomplete support for running from a source build. To confirm this, I installed pythonv - and then running pmv.py produces the expected result -

Re: [Distutils] pythonv, take two

Hi Vinay, On 03/29/2011 07:00 PM, Vinay Sajip wrote: If we switch to sys.virtual_prefix and leave sys.prefix alone, the danger would be that some installer that's using sys.prefix directly, and ignoring sysconfig.py, would try to install stuff to the global Python installation. But I'm not

Re: [Distutils] pythonv, take two

On 03/30/2011 07:18 PM, Vinay Sajip wrote: So... it seems to me that we're likely to break _some_ third-party code using sys.prefix regardless of what we do here. My instinct says adding sys.virtual_prefix and leaving sys.prefix alone is the better approach, but I'm not very firmly entrenched

Re: [Distutils] pythonv, take two

On 03/30/2011 11:23 PM, P.J. Eby wrote: At 01:35 PM 3/30/2011 -0400, Carl Meyer wrote: So... it seems to me that we're likely to break _some_ third-party code using sys.prefix regardless of what we do here. My instinct says adding sys.virtual_prefix and leaving sys.prefix alone is the better

Re: [Distutils] pythonv, take two

Hi Vinay, On 03/29/2011 09:45 AM, Vinay Sajip wrote: I've been thinking about the C-level configuration some more (cpythonv issue #6). Suppose we have a virtual env at absolute path testenv, and in testenv/bin we have a copied, non-installed Python, obtained from absolute path pythonsrc. Say

Re: [Distutils] issues with namespace packages on Debian Squeeze and Python 2.6

On 03/22/2011 06:50 AM, Reinout van Rees wrote: On 11-03-11 14:27, Barry Warsaw wrote: I have tried with system default python 2.5, and namespace packages works. The same when I create a virtual environment with python 2.6. The problem seems to just be with system default python 2.6. I'm

Re: [Distutils] reservations about pythonv

Hi Leonardo, On 03/19/2011 08:18 PM, Leonardo Rochael Almeida wrote: Another variant of this case, one we're actually facing here at our company (Nexedi) right now, is when you need to compile extension modules with libraries that are newer than the ones in the system, and you don't have root

Re: [Distutils] pythonv: let's also make sure the standard Python install includes an isolated python

On 03/17/2011 09:33 PM, Barry Warsaw wrote: On Mar 17, 2011, at 07:53 PM, Carl Meyer wrote: * executable-name has the extension stripped on Windows, but not otherwise. It should probably also have the extension stripped on OS X too. Hmm, really? What extension does the executable typically

Re: [Distutils] pythonv: let's also make sure the standard Python install includes an isolated python

On 03/17/2011 08:35 PM, P.J. Eby wrote: * I eliminated any form of generically-named config file, as I think the extra possible names (and thus possible sources of confusion) is not really worth the benefit. The only use case I can think of is if you have multiple python binaries or symlinks

Re: [Distutils] pythonv, take two

Hi Vinay, Thanks for the additional digging in here. I think your analysis is right - it actually occurred to me yesterday that this could be the problem, and I filed a bug to track it here: https://bitbucket.org/carljm/cpythonv/issue/6/if-binary-is-copied-prefix-finding-could The issue is

Re: [Distutils] reservations about pythonv

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Mark, On 03/18/2011 01:46 PM, Mark Sienkiewicz wrote: Here is a case that might resemble what you are talking about: Compile a C extension that requires a shared library that is not in the standard system path. To import it, LD_LIBRARY_PATH

Re: [Distutils] pythonv, take two

On 03/18/2011 05:24 PM, Tres Seaver wrote: Could the config file contain an optional hint for finding the right stdlib in cases where the binary copy had been made? I realize that parsing a config file *without* the stdlib is painful: perhaps looking for a line starting with 'stdlib =' would

Re: [Distutils] pythonv, take two

On 03/18/2011 07:22 PM, Éric Araujo wrote: 1. It seems... tempting but ill-advised to make it a fake ConfigParser option if in the place where I use it, I'm not actually parsing the file with full ConfigParser semantics. It might work, but then someone tries to get clever with a [DEFAULT]

Re: [Distutils] pythonv, take two

Hi Vinay, On 03/17/2011 06:25 AM, Vinay Sajip wrote: It seems to work with a symlink but not with a copy. With an empty pythonv.conf file in ~/projects/vptest: vinay@eta-natty:~/projects/vptest/bin$ ln -s ~/tools/cpythonv/python vinay@eta-natty:~/projects/vptest/bin$ ./python Python

Re: [Distutils] reservations about pythonv

On 03/17/2011 10:56 AM, Barry Warsaw wrote: Thanks for helping bolster my memory! I still think setting $LD_LIBRARY_PATH won't be necessary in the majority of cases, so generally no re-exec should happen. I can imagine that if it *were* necessary, an appropriate section in the pythonv.conf

Re: [Distutils] pythonv: let's also make sure the standard Python install includes an isolated python

On 03/17/2011 10:59 AM, Barry Warsaw wrote: On Mar 17, 2011, at 08:07 AM, Jim Fulton wrote: Whatever mechanism we end up with, I suggest that a standard python install include an isolated configuration. This is a common use case and should be available without having to create a virtualenv

Re: [Distutils] pythonv: let's also make sure the standard Python install includes an isolated python

On 03/17/2011 01:23 PM, Jim Fulton wrote: My understanding of how this will work was that I could created this myself by creating some sort of configuration file, say clean.cfg and then link a Python executable to the name clean. Reading pythonv, take two more carefully, I see that it is a

Re: [Distutils] pythonv, take two

On 03/16/2011 11:04 PM, Barry Warsaw wrote: +1. Time for a PEP? Working on a draft PEP. I'll push it to bitbucket to make collaboration easier - then the next step would be to present the draft on python-ideas, if I'm reading PEP 2 correctly? Carl

Re: [Distutils] pythonv: let's also make sure the standard Python install includes an isolated python

On 03/17/2011 03:00 PM, P.J. Eby wrote: At 01:41 PM 3/17/2011 -0400, Carl Meyer wrote: Actually, now that I come to think of it, pythonv (take two) does already cover your requirement. If you have a symlinked or copied python binary, and an empty pythonv.conf one directory up, Is there any

Re: [Distutils] pythonv: let's also make sure the standard Python install includes an isolated python

On 03/17/2011 01:53 PM, Jim Fulton wrote: It occurs to me that it would be nice if site.py could grow knowledge of whether -S was used and not automatically mutate the path if -S was used. That would allow -S to work robustly without having to link anything or create a config file. This

Re: [Distutils] pythonv: let's also make sure the standard Python install includes an isolated python

On 03/17/2011 05:13 PM, Jim Fulton wrote: I suggest the following: Look for argv[0]+'.pythonv' and then for '../pythonv.cfg'. So if I've linked the Python executable to ./bin/clean, look for ./bin/clean.pythonv and ./pythonv.cfg. Nice - I like the ability to have multiple interpreters

Re: [Distutils] pythonv: let's also make sure the standard Python install includes an isolated python

On 03/17/2011 04:39 PM, Barry Warsaw wrote: Bikeshedding time: how about something a little more descriptive? $ python -m virtualize path/to/new/env Ok, that color will do nicely. Carl ___ Distutils-SIG maillist - Distutils-SIG@python.org

Re: [Distutils] pythonv: let's also make sure the standard Python install includes an isolated python

FWIW, I've pushed a reworking of the config-file-finding, with the following shed-paint color choices: * File is named executable-name.virtual.conf (I kept the .virtual, despite it being longer and not strictly necessary, because I think it more clearly expresses the function of the file. The

[Distutils] early preview of pythonv

Hello all, Here at PyCon we've had some discussion about building a virtualenv-alike into Python core for Python 3.3. The goal is to improve on virtualenv by providing something that does what virtualenv does without requiring a copied Python binary, symlinked/copied parts of the standard

Re: [Distutils] early preview of pythonv

I forgot to mention - the code for this is in the pythonv named branch in the mercurial repo I linked (https://bitbucket.org/carljm/cpythonv), so you'll need to hg update pythonv after cloning to see it. Carl On 03/16/2011 04:31 AM, Carl Meyer wrote: This is an early prototype

Re: [Distutils] window 64bit madness

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/16/2011 08:38 AM, Adam GROSZER wrote: On 03/16/2011 12:09 PM, Lennart Regebro wrote: Out of curiosity, how does pip handle this? Not much better. http://paste.lisp.org/+2KZE/2 and pip install reportlab==2.5 fails with the usual no

Re: [Distutils] early preview of pythonv

Jim, On 03/16/2011 08:00 AM, Jim Fulton wrote: [snip] buildout. In particular, I know of 2 basic use cases: - Get complete isolation from local additions relative to the standard Python distribution. This is the primary design goal, and I believe it's currently achieved. To be clearer,

Re: [Distutils] early preview of pythonv

be implemented for 3.x. Regards, Antonio On Wed 16/03/11 13:00, Jim Fulton j...@zope.com wrote: On Wed, Mar 16, 2011 at 4:31 AM, Carl Meyer carl@oddbird .net wrote: Hello all, Here at PyCon we've had some discussion about building a virtualenv-alike into Python core for Python 3.3. The goal

Re: [Distutils] early preview of pythonv

: [Distutils] early preview of pythonv To: Distutils-Sig@Python.Org Carl Meyer carl at oddbird.net writes: This is an early prototype and will certainly require refinement (not to mention most likely a PEP, at some point). Please try it out and let me know if it works for you! I haven't tried it yet

Re: [Distutils] reservations about pythonv

This alternative approach (with a symlink and config file) sounds pretty good to me as well after our discussion at the sprints. The downsides I see: 1. Cross-platform inconsistency. Windows virtualenvs would be isolated from system python binary upgrades, *nix would not (some, like Brandon,

[Distutils] pythonv, take two

Hi all, I've pushed this symlink/copy binary approach to the pythonv2 branch at http://bitbucket.org/carljm/cpythonv. I was a bit shocked at how easy it turned out to be: just a few lines in site.py and the same changes to sysconfig.py as previously. No changes in C code needed at all. It was so

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

FWIW, when I've been writing docs or answering packaging questions and trying to use the approved, unambiguous terminology, using project for thing with a PyPI page has never been a problem; I've had much more difficulty in using distribution as the term for a zipfile or tarball or egg that you

Re: [Distutils] Python version in egg name

On 02/03/2011 11:24 AM, Matt Chaput wrote: Can people still use easy_install/pip to install it if it's not an egg? Yes. In fact, pip can only install from source distributions. A source .tar.gz is the most broadly-compatible distribution format available, unless your package includes compiled

Re: [Distutils] Unable to install packages after specifying package version

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 12/03/2010 05:55 AM, devyan parmar wrote: i am trying to install package from my packageserver using PIP. for example: m trying /bin/pip install --extra-index-url=http://mypkgserver/dev package_name==2.4.12b 2.4.12b is the version

[Distutils] [issue113] namespace packages installed with --single-version-externally-managed break other packages in that namespace

New submission from Carl Meyer c...@oddbird.net: When a namespace package is installed using the --single-version-externally-managed flag, setuptools generates a special nspkg .pth file for that package to make it work as a namespace package (instead of calling pkg_resources.declare_namespace

Re: [Distutils] pip vs easy_install vs distutils2

Hi Lennart, Lennart Regebro wrote: You are aware that pip uninstalls? Not reliably, as it doesn't keep track of files, so it can't remove anything installed outside of the package. Not true, inasmuch as it depends on pip. When pip installs distributions it uses the --record option to keep a

Re: [Distutils] pip vs easy_install vs distutils2

Lennart Regebro wrote: 1. We include easy_install or pip in stdlib. However, I think we shouldn't include any installer in stdlib, until it has evolved into a proper package handling utility which also can uninstall, etc. You are aware that pip uninstalls? It also queries PyPI, lists locally

Re: [Distutils] problems with namespace package

Manlio Perillo wrote: Can someone else confirm that namespace packages do not work with virtualenv? I can confirm the contrary; I use namespace packages regularly with virtualenv and have not had any problems. Carl ___ Distutils-SIG maillist -

Re: [Distutils] how to make pip do install using a requirements-files in order?

Hi, mouad ben wrote: I use pip with distribute and virtualenv to make an automatic install of a Django project . my problem is that i want to make the installation in the order that they came in the requirements-files that i specified. i use this command : pip install -E gold/ -r

Re: [Distutils] [Python-Dev] At least one package management tool for 2.7

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Darren, Darren Dale wrote: [snip] Thanks for responding, but I'm still wondering if pip can install dependencies recursively. Yes, it can and does. As Tarek said, pip uses the same install_requires metadata and it treats it the same way as

  1   2   >