On Wed, Jun 19, 2013 at 4:50 PM, Jason R. Coombs wrote:
>
> What’s the next step to support this bootstrap script?
Can you just upload it with the docs?
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailm
On Wed, Jun 5, 2013 at 2:47 PM, Donald Stufft wrote:
> One of the big problems with download_url is that the data in setup.py is
> used in (and influences the content of) the final dist file. This means that
> inside of a setup.py you won't know what the hash of the final file is. So
> it's diffic
On Tue, Jun 4, 2013 at 4:25 AM, Dariusz Suchojad wrote:
> But for now, given that you said you'd like not to interfere with previous
> releases, could you please upload 0.6c12dev-r88846 back to
> http://peak.telecommunity.com/snapshots/ or other places where it can be
> usually found?
The snapsho
On Sat, Jun 1, 2013 at 4:29 PM, Lennart Regebro wrote:
> On Sat, Jun 1, 2013 at 9:20 PM, Paul Moore wrote:
>> I'm -1 on anything that doesn't involve at least a minimal level of human
>> involvement (possibly excepting an initial clean up exercise for projects
>> with no author email)
>
> This is
On Sat, May 25, 2013 at 7:02 PM, Jason R. Coombs wrote:
> I heard in person by a newer
> Windows user recently, that they still hear that Setuptools is still
> considered friendlier than Distribute.
Without knowing what exactly they considered friendlier, I'm not sure
what to suggest. Even if yo
On Sat, May 25, 2013 at 4:40 PM, Jason R. Coombs wrote:
> https://bitbucket.org/pypa/setuptools/downloads
You may be already aware of this, but the installation instructions
don't match the available downloads. I was previously thinking we
should just drop binary distributions of setuptools al
On Sat, May 25, 2013 at 4:06 AM, Matt Wilkie wrote:
>>>... or use a script that doesn't depend on entry points
>
> not desirable, as we like the .exe entry points creates and don't want
> to use a batch file (the "are you sure you want to quit?" message on
> ctrl-c is annoying)
>
>>>, or copy your
On Wed, May 22, 2013 at 8:12 PM, Matt Wilkie wrote:
> How do I get my installer to include Distribute so I don't have to tell our
> users "before you install our program you have to go install this other
> program"?
Setuptools (which Distribute is based on) is designed for shipping
libraries, not
On Mon, May 20, 2013 at 1:03 PM, Lennart Regebro wrote:
> On Mon, May 20, 2013 at 6:05 PM, PJ Eby wrote:
>> On Sun, May 19, 2013 at 7:26 PM, Richard Jones wrote:
>>> Donald wrote a handy script to help make this easier:
>>>
>>> https://pypi.python.org/pypi/
On Sun, May 19, 2013 at 7:26 PM, Richard Jones wrote:
> Donald wrote a handy script to help make this easier:
>
> https://pypi.python.org/pypi/pypi-show-urls
Doesn't seem to work for me:
$ pypi-show-urls -u pje
Traceback (most recent call last):
File "/usr/bin/pypi-show-urls", line 8, in
On Sun, May 19, 2013 at 4:58 AM, holger krekel wrote:
> Tensed to see how many people will switch without the mails
I'll be waiting for the mails, myself, on account of I'm hoping it'll
give me a nice list of which of my packages I can switch, so as not to
need to go check on all of them myself.
On Sun, May 19, 2013 at 4:12 AM, Huiqun Zhou wrote:
> Hi,
>
> I'm trying to install numpy, but got the following error message. What's
> wrong?
You're using an older version of setuptools or distribute that doesn't
support packages writing to /dev/null in their installation scripts.
If you are
On Wed, May 15, 2013 at 7:17 AM, Eric V. Smith wrote:
> It looks like space causes most of the issues. I'm not sure how
> "Twisted Flow >= 1.0" would be expected to parse.
You would spell it "Twisted-Flow>=1.0", at least for setuptools-based
tools. Setuptools already restricts effective package
On Sat, May 4, 2013 at 8:01 PM, Donald Stufft wrote:
> The easiest way is to just bundle the mozilla certs. They do all the work of
> keeping it up to date and validating them.
Actually, it turns out that there's already a separately-distributed,
separately licensed PyPI package for this:
https:
On Thu, May 2, 2013 at 1:41 PM, M.-A. Lemburg wrote:
> On 25.04.2013 16:42, M.-A. Lemburg wrote:
>> The latest pip supports HTTPS URLs and certificate checks
>> (according to the change log).
>>
>> Will there be a release of distribute that implements the
>> same changes ?
>>
>> The current 0.6.36
On Sun, Apr 28, 2013 at 5:12 AM, Vinay Sajip wrote:
>
> I must be missing something - why not something like
>
> def ensure_unicode(s):
> if not isinstance(s, text_type): s = s.decode('unicode_escape')
> return s
>
> assuming you only ever pass bytestrings or Unicode in s, and text_type is
On Sat, Apr 27, 2013 at 6:13 PM, Daniel Holth wrote:
> So who's going to check how much long strings in json really cost?
I'm not sure how that's relevant, except for READMEs. Right now the
long description is how you get a decent homepage for your project on
PyPI; but there are no other use cas
On Sat, Apr 27, 2013 at 1:45 PM, Daniel Holth wrote:
> How do you feel about parenthesis?
Without them, you have to express everything in DNF (disjunctive
normal form), which usually means a lot of subexpression duplication
when you want to express something like "(a or b) and (c or d)"; it
woul
On Sat, Apr 27, 2013 at 6:38 PM, Vinay Sajip wrote:
>> I was not proposing that we support inequalities. They aren't so
>
>> problematic in themselves, as they are inviting various questions and
>> issues such as why they don't do any sort of version parsing.
>
> I'm not sure that platform_versio
On Sat, Apr 27, 2013 at 12:54 PM, Daniel Holth wrote:
> Do we really have to optimize the metadata for runtime parsing, or can
> we have a distlib-specific indexing operation triggered by the
> installer?
As long as the same thing is done inside a zipped wheel, duplication
of the data is ok by me
On Sat, Apr 27, 2013 at 2:35 PM, Vinay Sajip wrote:
> So IIUC, that just means that the variables we support in expressions are:
>
> * python_version, python_full_version, extra as in the PEP already.
> * os_name instead of os.name.
> * sys_platform instead of sys.platform
> * platform_version ins
On Sat, Apr 27, 2013 at 11:57 AM, Vinay Sajip wrote:
> Daniel Holth gmail.com> writes:
>
>> Surely getting farther away from python by trying to prohibit useless
>> makers just makes the implementation needlessly complex.
>
> I'm not quite sure what you mean by "useless" markers. For example, dis
On Sat, Apr 27, 2013 at 11:17 AM, Nick Coghlan wrote:
> It's not especially pretty, but it's better than having to use
> os.listdir and rely on predefined file names.
For entry points at least, having a predefined file name is the
*entire point*: i.e. to allow the presence of entry points to be
d
On Sat, Apr 27, 2013 at 5:46 AM, Vinay Sajip wrote:
> Sorry if I'm being dense, but can you confirm that what you mean by
> "chaining" is something like "a < b <= c"?
Yes.
> Things can be tightened up once PEP 426 is finalised.
Not if anybody's going to be using distlib between now and then,
u
I notice that distlib appears to support chaining of comparisons, but
the PEP does not. ISTM that there is no sane use case for chaining,
given the nature of comparisons that are allowed. (That is, if you
perform one equality or contains comparison between two values, then
you know how the next c
On Fri, Apr 26, 2013 at 2:52 AM, Nick Coghlan wrote:
> Yes, I think I prefer this layout for runtime consumption. Getting the
> full value for a field would then just be something like:
>
> # Core dependencies
> deps = meta["requires"]
> # Check dependencies for any specified optional
On Wed, Apr 24, 2013 at 1:33 PM, Vinay Sajip wrote:
> Erik Bernoth gmail.com> writes:
>> distlib is currently still in alpha and will likely be added under the
>> hood into setuptools anyway, when it's time.
>
> Not sure about that - it's meant to supplant setuptools and avoid setup.py
> altogeth
On Thu, Apr 25, 2013 at 9:50 PM, Nick Coghlan wrote:
> Note that == and != don't emit TypeError with non-comparable types -
> if both sides return NotImplemented from the corresponding magic
> methods, then the comparison is just False for == and True for !=.
> It's only the ordering comparisons t
I was just fiddling with an experimental environment marker
implementation for setuptools, and ran across a bit of a quirk in the
spec. It says that the value of 'extra' is 'None', but that
comparisons can only be done on strings.
This leads to two problems: first, the syntax doesn't have a way t
On Tue, Apr 9, 2013 at 2:41 AM, Christian Theune wrote:
> The simplest solution on a static mirror that I can see for this would be
> (with nginx) a "missing files" rule that redirects to PyPI. However, that
> would be bad form as that would cause *any* 404-triggering request on a
> mirror to hit
On Sat, Apr 6, 2013 at 10:03 AM, david bennett
wrote:
> G'day
> AIM: i'm trying to use Drive API with Python 2.7.3 to read and write files.
>
> PROBLEM: is with the install of "easy_install" (ironic, i know)
>
> 1. I have enabled the drive api
> 2. I can see that the google client library must be
On Sun, Apr 7, 2013 at 9:36 AM, Christian Theune wrote:
> The internal mechanisms of PEP 381 and the way that clients can authenticate
> the mirrored packages is not compatible with a partial mirror as the index
> pages are not generated but taken byte-by-byte so they can be verified with
> PyPIs
On Sun, Mar 31, 2013 at 1:09 PM, Philippe Ombredanne
wrote:
> On Sat, Mar 30, 2013 at 8:22 PM, Daniel Holth wrote:
>> Python ZIP Application Support -
>> https://docs.google.com/document/d/1MKXgPzhWD5wIUpoSQX7dxmqgTZVO6l9iZZis8dnri78/edit?usp=sharing
>> PEP: 4XX
>> Title: Improving Python ZIP App
On Sun, Mar 31, 2013 at 5:43 PM, PJ Eby wrote:
> In practice, there are a couple of wrinkles. The magic terminator
> string, at least for the Windows and Linux boxes I've tested so far,
> is '\n#\x1a\n\x00\n'. But there are more platforms and builds I
> *haven
On Fri, Mar 29, 2013 at 5:28 PM, Marcus Smith wrote:
> Some of the pypa people have been discussing beginning a "packaging-user"
> mailing list.
>
> - It would be open to *any* packaging or install user issues.
> - It would be on python.org
> - pip/virtualenv would use it instead of our "virtualen
On Fri, Mar 29, 2013 at 4:50 PM, Nick Coghlan wrote:
> On Sat, Mar 30, 2013 at 6:42 AM, PJ Eby wrote:
>> On Fri, Mar 29, 2013 at 3:55 PM, Nick Coghlan wrote:
>>> No, mutating sys.path for versioned imports is a broken design. You
>>> end up with two possibilities:
&g
On Fri, Mar 29, 2013 at 3:55 PM, Nick Coghlan wrote:
> No, mutating sys.path for versioned imports is a broken design. You
> end up with two possibilities:
>
> * If you append, then you can't override modules that have a default
> version available on sys.path. This is not an acceptable restrictio
On Thu, Mar 28, 2013 at 5:15 PM, Jacob Kaplan-Moss wrote:
> C'mon, folks, we're arguing about a name. That's about as close to
> literal bikeshedding as we could get.
I'm not arguing about the *name*. I just don't see the point in
making everybody subscribe to a new list and change their mail fi
On Thu, Mar 28, 2013 at 3:43 PM, Donald Stufft wrote:
> On Mar 28, 2013, at 3:39 PM, PJ Eby wrote:
>> Can we do it by just dropping catalog-sig and keeping distutils-sig?
>> I'm afraid we might lose some important distutils-sig population if
>> the process
On Thu, Mar 28, 2013 at 1:54 PM, Steve Dower wrote:
> And, I'm almost certain that most if not all existing ZIP tools on Windows
> will fail to open files with a shebang, since they've never had to deal with
> them.
Actually, the opposite is true, at least for 3rd-party (non-Microsoft)
archivin
On Thu, Mar 28, 2013 at 3:14 PM, Fred Drake wrote:
> On Thu, Mar 28, 2013 at 2:22 PM, Donald Stufft wrote:
>> Is there much point in keeping catalog-sig and distutils-sig separate?
>
> No.
>
> The last time this was brought up, there were objections, but I don't
> remember what they were. I'll l
On Wed, Mar 27, 2013 at 11:46 PM, Donald Stufft wrote:
> catalog-sig without an argument? Is this a first? ;)
No.
This!
Is!
Spart... uh, I mean, DISTUTILS-SIG! ;-)
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mail
On Wed, Mar 27, 2013 at 10:09 PM, Donald Stufft wrote:
> Right, which is why I think the ability to install from a raw source is a
> good feature for an installer, but not for the dependency metadata.
Sure - I never said the dependency metadata had to be able to say
*where* you get the raw sourc
On Wed, Mar 27, 2013 at 6:55 PM, Donald Stufft wrote:
> I still think I prefer a setup.py develop or develop.py to invoke the build
> system for development builds
It's possible we're not talking about the same thing -- I notice you
keep mentioning "setup.py develop", which is entirely unrelated
On Wed, Mar 27, 2013 at 1:51 PM, Donald Stufft wrote:
> I don't think the packaging formats should dictate the development flow at
> all. .IN files and such all dictate how that should be.
You can't *not* dictate the flow. If you don't have something to
generate the file with, then you're dicta
On Wed, Mar 27, 2013 at 1:09 PM, Daniel Holth wrote:
> I would be pleased if "pip install" lost
> the ability to natively install sdists without that intermediate step.
At that point, it would be giving easy_install (or any other tool that
did) a comparative advantage. So that's probably not goi
On Wed, Mar 27, 2013 at 8:02 AM, Vinay Sajip wrote:
> To those people who would balk at editing JSON by hand - who's asking you
> to? Why not just get the data into an appropriate dict, using any tools you
> like, and then serialise it to JSON?
The challenge here is again the distinction between
On Tue, Mar 26, 2013 at 8:33 PM, Donald Stufft wrote:
> As far as I can tell the only things that even use PKG-INFO is
> setuptools/distribute and we want to phase them out of existence anyways.
The only thing setuptools uses it for is to find out the version of a
package in the case where an .e
On Tue, Mar 26, 2013 at 3:03 PM, Daniel Holth wrote:
> I think PKG-INFO is a highly human-editable format.
That doesn't mean you necessarily want to edit it yourself; notably,
there will likely be some redundancy between the description in the
file and other files like the README.
Also, today on
On Tue, Mar 26, 2013 at 12:46 PM, Daniel Holth wrote:
> I suspect at least 80% of packages will use some simple thing that
> comes with Python, two third party build tools will dominate, and we
> will discover interesting things that just weren't possible before. At
> least if someone wants to imp
On Mon, Mar 25, 2013 at 11:35 PM, Daniel Holth wrote:
> The problem we are solving first is not "setuptools", it is simply
> that right now Python programs are usually installed by downloading
> and then running a program that performs the actual install. Instead,
> we're going to let the installe
On Mon, Mar 25, 2013 at 5:08 PM, Paul Moore wrote:
> There's a longer-term issue that occurred to me when thinking about
> pip's role as a "builder" or an "installer" (to use Nick's
> terminology).
>
> As I understand Nick's vision for the future, installers (like pip)
> will locate built wheels a
On Mon, Mar 25, 2013 at 1:23 PM, Daniel Holth wrote:
> It is going to be problematic to try to find and download legacy eggs
> correctly and automatically since they don't for example tell you
> whether they are wide Unicode. Those problems and more would apply to
> automatically downloading and c
On Wed, Mar 20, 2013 at 10:35 AM, Nick Coghlan wrote:
> Assuming we go this way, distros will presumably install system Python
> packages
> into the versioned layout and then symlink them appropriately from the
> "available by default" layout in site-packages.
If they're going to do that, then w
On Wed, Mar 20, 2013 at 8:29 AM, Nick Coghlan wrote:
> I'm not wedded to using *actual* pth files as a cross-platform linking
> solution - a more limited format that only supported path additions,
> without the extra powers of pth files would be fine. The key point is
> to use the .dist-info direc
On Wed, Mar 20, 2013 at 12:42 PM, Erik Bray wrote:
> Quick question regarding open issues on Distribute (of which I have a
> handful assigned to me, and of which I intend to tackle a few others):
> Would it it make sense to just hold off on those until the merge is
> completed?
I'd personally sa
On Tue, Mar 19, 2013 at 1:02 PM, Nick Coghlan wrote:
> The "but what
> about long sys.paths?" problem can be dealt with as a performance
> issue for the import system.
And already has been, actually. ;-)
In addition to the changes made in the import system for 3.3, there's
another improvement p
On Tue, Mar 19, 2013 at 2:04 PM, Richard Jones wrote:
> The Fedora variant of Linux has had a separate program called "pip" (a Perl
> package installer) available for install for some time. The current Python
> "pip"
> program is installed as "pip-python". It is hoped that the Fedora community
>
On Mon, Mar 18, 2013 at 6:04 PM, Nick Coghlan wrote:
> pkg_resources.requires() is our only current solution for parallel
> installation of incompatible versions. This can be made to work and is
> a lot better than the nothing we had before it was created, but also
> has quite a few issues (and it
On Tue, Mar 19, 2013 at 5:06 AM, Adam GROSZER wrote:
> Looks like running
> python.exe setup.py test
> is the right command to run the tests, isn't it?
It certainly should be. As I said, I'm not familiar with the
distribute side, so maybe Jason or somebody else can lend a hand here.
I know the
On Thu, Mar 14, 2013 at 5:05 AM, Adam GROSZER wrote:
> I think I can offer you some help, by providing some windows support in the
> means of testing with various python versions and building binary
> packages/installers.
>
> Note, current tests are failing...
>
> http://winbot.zope.org/builders
On Wed, Mar 6, 2013 at 8:20 AM, Paul Moore wrote:
> On 6 March 2013 12:50, Vinay Sajip wrote:
>> Still no joy with the uninstalled setuptools, then? It seemed to work for me
>> without any special work, but that was on Linux.
>
> Yeah, again it seems to be subtle environmental issues. Sometimes
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. I appreciate the
contributions made by the distribute mai
On Mon, Mar 11, 2013 at 11:36 AM, Erik Bray wrote:
> On Sat, Mar 9, 2013 at 9:33 PM, PJ Eby wrote:
>> On Sat, Mar 9, 2013 at 8:14 PM, Nick Coghlan wrote:
>>> Longer term, something like the import engine PEP may let us implement a
>>> cleaner solution.
>>
>
On Sat, Mar 9, 2013 at 8:14 PM, Nick Coghlan wrote:
>
> On 10 Mar 2013 10:16, "Vinay Sajip" wrote:
>>
>> Paul Moore gmail.com> writes:
>>
>> > Would it be worth considering splitting distlib into two separate
>> > parts - one that is intended solely for writers of installers and
>> > similar too
On Sat, Mar 9, 2013 at 1:28 PM, Paul Moore wrote:
> Would it be worth considering splitting distlib into two separate
> parts - one that is intended solely for writers of installers and
> similar tools, and another for "runtime support" functions that end
> users would use? It may not be a practic
On Mon, Mar 4, 2013 at 3:20 PM, Paul Moore wrote:
> On 4 March 2013 20:00, Daniel Holth wrote:
>> On Mon, Mar 4, 2013 at 2:41 PM, Paul Moore wrote:
>>> In thinking about how virtualenv would describe the packages it wants
>>> to preload in PEP 426 metadata form, it occurred to me that there are
On Mon, Mar 4, 2013 at 2:41 PM, Paul Moore wrote:
> In thinking about how virtualenv would describe the packages it wants
> to preload in PEP 426 metadata form, it occurred to me that there are
> scenarios with setuptools and distribute where it's not obvious how to
> state the requirement you wan
On Mon, Feb 25, 2013 at 9:39 AM, Nick Coghlan wrote:
> (This probably belongs in a successor to PEP 376, but I'll leave it
> under the PEP 426 umbrella for now)
>
> One of the points raised regarding PEP 426's integrated metadata
> format is the potential for runtime issues with pkg_resources as i
On Fri, Feb 22, 2013 at 3:57 PM, Manlio Perillo
wrote:
> Hi.
>
> I have find an inconstistency when using the pkg_resources module with
> namespace packages.
>
> I'm using setuptools 0.6c11-py2.5.egg
>
> Here is an interactive session:
>
import pkg_resources
dist = pkg_resources.Requirem
On Tue, Feb 19, 2013 at 9:20 AM, Eric V. Smith wrote:
> 2. Does the metadata need to contain information about namespace
> packages? It's settable in distribute/setuptools' setup.py. I'm not sure
> if the need for it has been obviated by PEP 420 or not.
I don't think distutils or any of its exten
On Sat, Feb 16, 2013 at 7:40 AM, Vinay Sajip wrote:
> Nick Coghlan gmail.com> writes:
>
>> That suggests to me that a separate "clean" command in the PEP 376
>> aware tools would be a better choice, where it looks for directories
>> that are either empty or contain only __pycache__ subdirectories
On Sat, Feb 16, 2013 at 7:08 AM, Nick Coghlan wrote:
> The main problem I can see is with namespace packages: you could get a
> "Do you want to delete this directory?" every time you uninstalled a
> distribution that contributed files to a namespace package.
Actually, the idea of PEP 376 is that
On Thu, Feb 14, 2013 at 2:24 PM, Tarek Ziadé wrote:
> On 2/14/13 8:21 PM, PJ Eby wrote:
>>
>> On Thu, Feb 14, 2013 at 1:52 PM, Tarek Ziadé wrote:
>>>
>>> On 2/14/13 6:32 PM, Jim Fulton wrote:
>>>>
>>>> On Thu, Feb 14, 2013 at 11:41 AM
On Thu, Feb 14, 2013 at 1:52 PM, Tarek Ziadé wrote:
> On 2/14/13 6:32 PM, Jim Fulton wrote:
>>
>> On Thu, Feb 14, 2013 at 11:41 AM, Tarek Ziadé wrote:
>>>
>>> Hey
>>>
>>> As Marc-André suggested, it would be a good thing to move the
>>> bootstrapping
>>> file to
>>> :https://pypi.python.org/packa
On Tue, Feb 12, 2013 at 3:48 AM, Ronald Oussoren wrote:
> The hook could be one or two new header fields in the PKG-INFO
> file, with a PEP that describes those keys and how the builder is invoked and
> what
> it is supposed to do. Am I understanding this correctly?
>
> Something like:
>
> Extens
On Mon, Feb 11, 2013 at 4:56 PM, Alessandro Dentella wrote:
> thanks for the answer but this way I need to really import jmb while
> imp.find_module doesn't really import it.
If you want to know whether the module 'jmb' exists, you can certainly
do that by using pkgutil.iter_modules(). What you
On Mon, Feb 11, 2013 at 11:40 AM, Alessandro Dentella wrote:
>
> I believe that this issue belongs to this list, please let me know if I'm
> wrong.
>
> Suppose I have 2 packages:
>
> jmb.foo
> jmb.bar
>
> distributed separately. Each has in jmb's __init__ a standard:
>
>
> __import__('pkg_re
On Wed, Jan 9, 2013 at 4:04 PM, Guy Rozendorn wrote:
> Hi,
>
> I'm trying to make ansible (https://github.com/Infinidat/ansible) compatible
> with easy_install (so I can use it later in places that use easy_install and
> not pip).
>
> When I install it with pip, everything works, but not with ea
On Tue, Jan 8, 2013 at 6:24 PM, Paul Moore wrote:
> On 8 January 2013 22:29, Christian Tismer wrote:
>> So why is it so difficult to just use "except ValueError as e" ?
>>
>> Am I missing the point, or would it not just work with python 2.7 and up?
>
> The problem is that distribute supports Pyt
On Fri, Jan 4, 2013 at 4:17 AM, Vinay Sajip wrote:
> The other thing is that using *only* relative paths doesn't cut it - there
> are circumstances where you write files outside site-packages, so you would
> need absolute paths for those files (or incredibly convoluted relative ones),
Actually,
On Mon, Dec 31, 2012 at 2:42 PM, Vinay Sajip wrote:
> If you move the files, other things can potentially break, too. For example,
> any scripts installed will have their shebangs adjusted to point to a
> particular interpreter, e.g. a venv's interpreter. If they get moved to a
> different locatio
On Sun, Dec 23, 2012 at 8:34 PM, Abduljalil Sireis wrote:
> Dear Nipype experts,
>
> i was trying to install nipype software by easy_install command and had the
> following error:
>
> install_dir /usr/loca/lib/python2.6/dist-packages/
> error: can't creat or remove files in install directory
>
>
On Sun, Dec 23, 2012 at 4:04 AM, Václav Šmilauer wrote:
> I would like to declare empty namespace package "A.B" inside the setup.py of
> "A", but I am getting
>
> error in A setup command: Distribution contains no modules or package
> for namespace package "A.B".
You need an __init__.py for A
On Fri, Dec 7, 2012 at 11:13 AM, Václav Šmilauer wrote:
> Hello,
>
> I am using setuptools to package module A. I would like to separately
> package also modules A.* such that those submodules are discoverable (using
> pkgutil.iter_modules preferrably) from within A, provided their names are
> unk
On Mon, Dec 3, 2012 at 2:05 AM, anatoly techtonik wrote:
> Hi,
>
> I disliked that setup.py creates its own temp directories without any
> private prefix, so I wanted to override this option in setup.py:
>
> $ setup.py build -h
> ...
> Options for 'build' command:
> --build-base (-b) base direc
On Wed, Nov 28, 2012 at 1:46 PM, Peterson, Stephen <
stephen_peter...@cable.comcast.com> wrote:
> I installed Jython 2.5.3 on Windows 7. I set up the environment variable
> to the main directory and the path. It works as I can type "jython" at a
> DOS prompt and see the >>> and the version statem
On Mon, Nov 26, 2012 at 3:10 AM, Chris Withers wrote:
>
> On 23/11/2012 22:11, PJ Eby wrote:
>
>> If you're still looking for an answer, pretty much all you can do for
>> that is: "setup.py develop easy_install pkgname[docs,testing]". You can
>> s
On Fri, Nov 23, 2012 at 2:53 PM, Chris Withers wrote:
> On 07/11/2012 18:36, Chris Withers wrote:
>
>> On 06/11/2012 12:23, Daniel Holth wrote:
>>
>>> On Nov 6, 2012, at 6:47 AM, Chris Withers wrote:
>>>
>>> On 05/11/2012 20:32, Daniel Holth wrote:
> Extras are just an alias for a set of
On Tue, Nov 20, 2012 at 3:18 AM, Ronald Oussoren wrote:
>
> On 19 Nov, 2012, at 20:26, PJ Eby wrote:
> >
> >
> > Data files should never be installed to package directories. But I'm
> not aware of any good reason why resource files should ever be installed
&
On Mon, Nov 19, 2012 at 2:37 PM, Paul Moore wrote:
> On 19 November 2012 19:26, PJ Eby wrote:
>
>> I think we should use some clearly-distinct (and mutually exclusive)
>> terminology going forward:
>>
>> * Data files: stuff the user can and/or should change,
On Sun, Nov 18, 2012 at 6:40 PM, Vinay Sajip wrote:
> Chris McDonough plope.com> writes:
>
> > >> That is not the definition of "resource" in setuptools-derived
> > >> systems. The definition of resource in setuptools-derived systems is
> > >> "a non-Python file that lives in a package", which i
On Sat, Nov 10, 2012 at 6:51 AM, Vinay Sajip wrote:
> Carl Meyer oddbird.net> writes:
>
> > already satisfied. In pip this happens here:
> > https://github.com/pypa/pip/blob/develop/pip/req.py#L1091
> >
> > More generally, I wouldn't really recommend pip's dependency resolution
> > logic as a mod
On Sat, Oct 27, 2012 at 7:08 PM, Vinay Sajip wrote:
> N.B. with the #egg=name-version scheme, as the fragment portion is not sent
> to the server, there's no way to expect that the server will always return
> a specific version (as no version is specified in the URL which goes to the
> server).
T
On Sat, Oct 27, 2012 at 5:57 AM, Vinay Sajip wrote:
> PJ Eby telecommunity.com> writes:
>
>>
>> Just as an FYI, are you aware of the #egg=projname-version tagging
>> convention currently in use for such links?
>
> I wasn't - thanks - still new to this game
On Thu, Oct 25, 2012 at 5:38 AM, Vinay Sajip wrote:
> 2. distlib (currently) skips archives automatically generated by sites like
>GitHub and BitBucket, since the download archive doesn't always contain
>version information in the name of the download. Examples:
>
>http://github.com/us
On Wed, Oct 17, 2012 at 11:25 PM, Daniel Holth wrote:
> An installer downloads an sdist. For each installed build plugin,
> .recognize(dir) is called. The first plugin to return True is used.
Why not just have a standard bit of metadata in an sdist that tells
the installer what builder(s) needs t
On Tue, Oct 9, 2012 at 7:53 PM, Daniel Holth wrote:
> would also like to be able to store my installed package database in
> sqlite3 by implementing an appropriate distlib/pkg_resources backend
> and defining a standard post-(un)install "index this new package" hook
> but I doubt I will have the (
On Tue, Oct 9, 2012 at 7:28 PM, Vinay Sajip wrote:
> I don't believe that wheels are meant to be directly importable, but I could
> be wrong about that. I am not sure why callee dependencies need to be
> transparently met by distributions not on sys.path; Broadly speaking, and
> leaving eggs out o
On Fri, Oct 5, 2012 at 2:38 PM, Paul Moore wrote:
> That's a good point. Actually, writing a "local PyPI server" is much
> easier if all you have to implement is the simple static page
> interface. So I take back some of my objection - both XML-RPC and the
> static page interface make sense to sup
101 - 200 of 276 matches
Mail list logo
