On 25 August 2013 20:53, PJ Eby wrote:
> FWIW, I would also note that if you use easy_install to install
> anything, you are quite possibly using multi-version installs without
> realizing it. (The __main__.__requires__ API is used in
> easy_install-generated script wrappers, so there isn't any
On 25 August 2013 23:14, PJ Eby wrote:
> > Unless I'm missing something, I suspect that this over-counts the number
> of
> > people using multi-version, in the sense that many (the majority?) of
> > wrapper scripts using multi-version do not actually need to,because the
> > users never install mo
On 27 August 2013 00:15, PJ Eby wrote:
> You pounced on a tiny piece of my email to Paul, in which I mainly
> expressed confusion about his statements about "cost". I was having
> trouble understanding what sort of "costs" he meant, and in subsequent
> discussion realized that it's because he an
On 27 August 2013 10:00, Nick Coghlan wrote:
> Just to scare people though... I did come up with a potentially decent
> use case for .pth files: they're actually a reasonable solution for
> sharing distributions between virtual environments in a way that works
> cross platform and on all currentl
On 29 August 2013 16:02, Oscar Benjamin wrote:
>On 29 August 2013 15:30, Antoine Pitrou wrote:
[...]
>> (after all, it's just "python setup.py build_bdist", or something :-))
>
> The point is that pip and other packaging tools will use 'python
> setup.py ...' to do all the building and wheel maki
On 30 August 2013 00:08, Nick Coghlan wrote:
> We also need to officially bless pip's trick of forcing the use of
> setuptools for distutils based setup.py files.
Do we? What does official blessing imply? We've managed for years without
the trick being "official"...
The main reason it is curre
On 30 August 2013 12:54, Oscar Benjamin wrote:
> setup.py that would satisfy those commands. It could be as easy as:
>
> if sys.argv[1] == 'bdist_wheel':
> sys.exit(subprocess.call(['bentomaker', 'build_wheel'])
>
> or whatever.
OK, inspiration moment for me. It had never occurred to me tha
On 30 August 2013 14:44, Donald Stufft wrote:
> The Windows and OSX installers distributed by Python.org will automatically
> attempt to run ``python -m getpip`` by default however the ``make install``
> and ``make altinstall`` commands of the source distribution will not.
>
Presumably the unins
On 3 September 2013 22:20, M.-A. Lemburg wrote:
> IMO, a much better way forward would be to integrate useful setuptools
> changes right back into distutils, so that the monkey patching
> no longer happens and python-dev can officially bless those
> set of changes.
>
I'm curious about this possi
On 4 September 2013 08:13, M.-A. Lemburg wrote:
> It's not about reinventing the wheel, it's taking the good bits
> from setuptools and moving them into distutils to make them
> standard for Python 3.4+, allowing setuptools to stop monkey patching
> distutils and extensions to stop relying on a se
On 4 September 2013 11:30, Donald Stufft wrote:
> On Sep 4, 2013, at 6:21 AM, "M.-A. Lemburg" wrote:
>
>> I quite like the idea of using setup.py as high level
>> interface to a package for installers to use, since that
>> avoids having to dig into the details built into the
>> setup.py code (and
On 4 September 2013 12:05, Oscar Benjamin wrote:
> Also would this be sufficient to decouple pip and setuptools (a
> reasonable goal in itself)? Or does pip depend on setuptools in more
> ways than the distutils monkey-patching?
I've not got round to reviewing the code (it's on my list) but I thi
On 4 September 2013 11:33, Antoine Pitrou wrote:
> Users don't want their security concerns to be dictated by a service
> provider. Programmatically refusing passwords which are deemed "too
> weak" is the kind of policy that I thought had disappeared since the 1990s
> (yes, it's been tried before,
On 4 September 2013 12:28, Paul Moore wrote:
> (Note by the way that the PyPI restrictions would not accept the
> complete text of the above paragraph as a valid password. I bet it has
> pretty high entropy, though...)
Whoops, missed the 16-character comment. Teach me to be sarcastic
On 4 September 2013 12:37, Oscar Benjamin wrote:
> What I meant was: If distutils gained the minimal missing setuptools
> commands then would that be sufficient to decouple setuptools and pip.
> I guess you've answered that above as "probably".
>
OK. But I regard vthat as a case of "if false then
On 4 September 2013 12:58, Nick Coghlan wrote:
> However, a more significant problem is that the whole idea is based on
> pure vapourware. That ideal "it's just like setuptools, but with a
> more elegant implementation that could be used to replace distutils in
> Python 3.4" library *doesn't exist
On 4 September 2013 14:18, Nick Coghlan wrote:
> If such projects publish wheel files (modulo us getting the Linux file
> naming problem sorted), then the only people the build issues are
> likely to hit are those that force builds from source (like
> zc.buildout and Linux distributions).
Persona
On 4 September 2013 14:27, Nick Coghlan wrote:
> I was under the impression pip *already* forced the use of setuptools
> (to ensure "--record" is available), so why would "pip wheel" provoke
> any more bug reports than "pip install"?
It won't, but at the moment the reports are likely to be that *
On 4 September 2013 17:20, Carl Meyer wrote:
> 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
On 7 September 2013 23:36, Carl Meyer wrote:
>> But if a distribution uses only distutils, it won't be declaring any
>> dependency metadata through install_requires=, setup_requires= etc. or any
>> other kwarg recognised only by setuptools - so where would the dependency
>> information come from?
On 8 September 2013 12:44, Oscar Benjamin wrote:
>> The *other* problem is that a custom implementation of an egg-info
>> command is pretty much certain to be incompatible with pip injecting
>> setuptools. And that's the big issue, injecting setuptools actively
>> prevents people writing their own
Is the spec at
http://peak.telecommunity.com/DevCenter/EasyInstall#package-index-api
still the definitive version of what must be provided for a local PyPI
index (for use by something like pip)? Or is there a more up to date
version anywhere?
For example, are MD5 signatures still the only support
On 9 September 2013 16:11, Donald Stufft wrote:
> It might match what easy_install looks for but it's not up to date. I think
> it's
> still written as if the simple index had not been created. That being said
> it'll probably mostly work. One of my steps I want to do with warehouse
> is actually
On 9 September 2013 16:27, Donald Stufft wrote:
> Does that help?
It does. A lot. Many thanks for that, I could probably have worked
most of it out but you've saved me a decent chunk of time.
Cheers,
Paul
___
Distutils-SIG maillist - Distutils-SIG@py
On 12 September 2013 15:38, Vinay Sajip wrote:
> The problem seems to be that in at least these two places, pip runs code
> looking like
>
> dist = pkg_resources.get_distribution('XXX')
>
> which of course will not find the setuptools or pip in the .pyz.
>
> Is this behaviour by design? If so, it
On 15 September 2013 16:33, Donald Stufft wrote:
[...]
> ``pip`` currently depends on ``setuptools`` to handle metadata generation
> during the build process, along with some other features. While work is
> ongoing to reduce or eliminate this dependency, it is not clear if that
> work will be comp
On 18 September 2013 12:49, M.-A. Lemburg wrote:
> Upside: It works with Python 2.x and 3.x.
> Downside: Unix only.
>From your description, it's not clear - is it just the installer
that's Unix-only, or the runtime as well? I just looked at the link,
apparently the runtime is as well, but I'm not
On 30 September 2013 18:55, Marcus Smith wrote:
> so, take a case like so "pytest-xdist-dev.tar.gz" (or any sdist with "-" in
> the project name, and a version starting with a string)
>
> I think it's like so:
> - pkg_resources.Distribution.from_location will treat "xdist-dev" as the
> version.
>
I'm having trouble using pkg_resources.get_distribution, and I'm not
sure if it's because what I'm trying to do is unsupported (likely) or
if I'm doing something wrong (also possible :-()
I have a wheel file - essentially a zip file containing a
distribution, plus a dist-info directory. If I put t
On 1 October 2013 18:51, Daniel Holth wrote:
> pkg_resources only finds distributions inside .egg and inside sys.path
> entries that are filesystem directories. You might be able to manually
> add a new Distribution instance to working_set or start looking for a
> place to add the feature here:
O
On 1 October 2013 21:32, PJ Eby wrote:
> On Tue, Oct 1, 2013 at 1:51 PM, Daniel Holth wrote:
>> pkg_resources only finds distributions inside .egg and inside sys.path
>> entries that are filesystem directories.
>
> Actually it looks in zipfiles (or subdirectory paths thereof) or
> filesystem dire
As part of PEP 453, there is a proposal to change the layout of python
environments on Windows by renaming the "Scripts" directory to "bin"
(to match other platforms). The PEP is targeted at Python 3.4 (core
and venv module) but for consistency virtualenv should also change to
match (only for virtu
On 15 October 2013 19:25, Ned Deily wrote:
> It might be worthwhile reviewing the discussion that took place on python-dev
> last year when Van Lindberg proposed changing the Windows file layout,
> including the scripts path.
>
> https://mail.python.org/pipermail/python-dev/2012-March/117552.html
On 15 October 2013 20:31, Paul Moore wrote:
> On 15 October 2013 19:25, Ned Deily wrote:
>> It might be worthwhile reviewing the discussion that took place on python-dev
>> last year when Van Lindberg proposed changing the Windows file layout,
>> including the scri
On 15 October 2013 22:33, Nick Coghlan wrote:
> It's only there because MvL didn't really want to add the existing Scripts
> directory to PATH.
Sorry to bang on about this, but do you mean PythonXY\Scripts (which
doesn't exist at install time and hence I can see why adding it to
PATH could be an
On 15 October 2013 23:17, Paul Moore wrote:
> 1. Use bin instead of Scripts (which means changing sysconfig and
> possibly distutils or 3rd party tools that hard code the name rather
> than using sysconfig).
By the way, I just did a scan. The following from the cpython repo
will need
On 15 October 2013 23:44, Nick Coghlan wrote:
>> Also, as a result of (3) existing wininst installers will not install
>> correctly on Python 3.4+ (they'll put their scripts in "Scripts"
>> still). So projects will need to distribute separate installers for
>> Python <= 3.3 and 3.4+ if they contai
With all of the current interest in bundling pip with the Python
distribution, I had a sudden thought. Vinay has developed a package
called pyzzer (https://pypi.python.org/pypi/pyzzer) that bundles up
Python modules into runnable single-file executables.
Using a command
pyzzer -m pip:main -l
On 21 October 2013 14:25, Vinay Sajip wrote:
> From what I can see 2 and 3 have been addressed in recent changes, but I
> couldn't tell from a quick reading whether 1 has been addressed (there have
> certainly been code changes in this area) or whether 4 has been addressed.
Yes, 3 in particular
On 21 October 2013 17:25, Vinay Sajip wrote:
> The default is "#!/usr/bin/env python", which should search the path for a
> Python executable, including on Windows as long as the latest launcher
> version is installed.
Not if you're using the exe launchers rather than a pyz file. The
supplied l
On 18 October 2013 18:44, Vinay Sajip wrote:
> version.py:
>
> Added support for PEP 440 version matching.
>
> Removed AdaptiveVersion, AdaptiveMatcher etc. as they don't add
> sufficient value to justify keeping them in.
AFAICT, you removed Version.suggest_normalized_version(), which
On 22 October 2013 10:54, Vinay Sajip wrote:
>> AFAICT, you removed Version.suggest_normalized_version(),
>> which breaks pip if we re-vendor to this version.
> No, it's just been renamed to _suggest_normalized_version. Public access is
> now via the version scheme.
OK, so it's now private. Is
On 22 October 2013 14:27, Vinay Sajip wrote:
> Yes, you can use it that way - sorry for any inconvenience.
No problem, it's what we get for using a library that's not reached a
stable version yet :-)
Paul
___
Distutils-SIG maillist - Distutils-SIG@pyt
On 1 November 2013 13:41, Ronald Oussoren wrote:
>
> If you build a Wheel with Homebrew Python will it work on the official OSX
> installers? What if I have a library installed from Homebrew? Essentially
> trying to figure out how likely it is that with the existing tags a wheel is
> going to work
On 1 November 2013 15:48, Chris Barker wrote:
> On Fri, Nov 1, 2013 at 6:59 AM, Paul Moore wrote:
>>
>> The key point here is the granularity of the PEP 425 tags used by wheel.
>>
>> The risk is that a wheel created on another system might declare (via
>> its fil
On 1 November 2013 22:36, Donald Stufft wrote:
> python -c "import distutils; print(distutils.util.get_platform().replace('.',
> '_').replace('-', '_'))"
> macosx_10_8_x86_64
OK, cool. That means that binary wheels will be specific to the OSX
version and the word size. Even more specific than W
On 1 November 2013 22:51, Donald Stufft wrote:
> How can I get the SOABI?
Sorry, didn't I include that before?
sysconfig.get_config_var('SOABI')
should do it.
Paul
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman
On 1 November 2013 22:58, Donald Stufft wrote:
> python -c "import sysconfig; print(sysconfig.get_config_var('SOABI’))"
> None
That implies no explicit ABI tag - the platform and Python version
tags are deemed sufficient to ensure interoperability.
Paul
__
On 1 November 2013 23:10, Greg Ewing wrote:
> Will there be a mechanism to get the actual MacOSX version
> needed into the metadata, rather than the one you happen
> to be building on?
There can be anything - the question here is really whether anything
is *needed*, or is what we have sufficient.
I'm trying to convert a setup.py to use setuptools (specifically the
docutils build, FWIW). The existing setup.py has some custom command
stuff to run 2to3 on build.
As I understand it, setuptools should do this automatically by using
use_2to3=True.
So, I've changed the code to just do:
setup(
On 11 November 2013 17:26, Marius Gedminas wrote:
> On Mon, Nov 11, 2013 at 04:29:32PM +0000, Paul Moore wrote:
>> I'm trying to convert a setup.py to use setuptools (specifically the
>> docutils build, FWIW). The existing setup.py has some custom command
>> stuff to ru
On 11 November 2013 20:45, Lennart Regebro wrote:
> If 2to3 is being run you'll get quite a lot of fairly obvious output
> to that effect. So it sounds like it's not.
>
> A quick look at bdist_egg seems to indicate that it never runs the
> build_py step, which is what runs 2to3. So this may be a b
On 16 November 2013 17:59, Thomas Heller wrote:
> What is the preferred format to distribute Python-3 libraries (for Windows)
> nowadays: wininst, egg, ...?
Wheel is the format of the future.
pip install will only use wheels (recent versions of pip)
wininst doesn't support virtualenv
egg is only
On 16 November 2013 21:59, Donald Stufft wrote:
> And sdist!
Sorry - I assumed compiled C extensions. You'll always provide sdist,
and unless you're distributing a compiled extension, that's all you'll
need. (Wheel distributions even for pure Python is the intention in
the future, but they aren't
I've not seen any documentation and/or code (other than the PEP) yet
for the _ensurepip changes that will be going into Python 3.4, but can
I check what the intention is for people using the extensibility API
in venv?
Specifically, if I want to install something as well as (or other
than) pip/setu
On 17 November 2013 23:53, Nick Coghlan wrote:
> It's covered in the PEP (including the venv module API changes):
> http://www.python.org/dev/peps/pep-0453/#changes-to-virtual-environments
Thanks (and sorry I missed that). And thanks for your other answer as well.
On 22 November 2013 17:06, Justin Cappos wrote:
>> "unclaimed" project. What's this? What is the process of "claiming a
>> project"? Is there a better terminology? This reads like picking abandoned
>> project or project without authorship.
>
>
> Yes, it is essentially a project where the owner has
On 30 November 2013 11:05, anatoly techtonik wrote:
> hi, please cc
>
> i want to release some versions to pypi, but hide them from installing
> by explicitly marking as pre-release. i want to preserve versions
> numbering as 0.1, 0.2 according to semver.org point 4. is that
> possible?
No, I don
On 1 December 2013 04:15, Nick Coghlan wrote:
> 2. For cross-platform handling of external binary dependencies, we
> recommend boostrapping the open source conda toolchain, and using that
> to install pre-built binaries (currently administered by the Continuum
> Analytics folks). Specifically, com
On 1 December 2013 19:21, Marcus Smith wrote:
>>> sometimes mean needing to build components with external dependencies
>>> from source
>
> you mean build once (or maybe after system updates for wheels with external
> binary deps), and cache as a local wheel, right?
Note that it is possible to co
On 1 December 2013 22:17, Nick Coghlan wrote:
> For example, I installed Nikola into a virtualenv last night. That required
> installing the development headers for libxml2 and libxslt, but the error
> that tells you that is a C compiler one.
>
> I've been a C programmer longer than I have been a
On 2 December 2013 07:31, Nick Coghlan wrote:
> The only problem I want to take off the table is the one where
> multiple wheel files try to share a dynamically linked external binary
> dependency.
OK. Thanks for the clarification.
Can I suggest that we need to be very careful how any recommenda
On 2 December 2013 10:45, Oscar Benjamin wrote:
> Nick's proposal is basically incompatible with allowing Cristoph
> Gohlke to use pip and wheels. Christoph provides a bewildering array
> of installers for prebuilt packages that are interchangeable with
> other builds at the level of Python code b
On 2 December 2013 13:22, Nick Coghlan wrote:
>> As a quick sanity check question - what is the long-term advice for
>> Christoph (and others like him)? Continue distributing wininst
>> installers? Move to wheels? Move to conda packages? Do whatever you
>> want, we don't care? We're supposedly pus
On 2 December 2013 07:53, Imran M Yousuf wrote:
> Hi,
>
> I am new to setuptools. I am using it to build and package a project
> of mine. Currently if I execute `python setup.py bdist` it generates a
> tarball with all files located in paths
> './abs/path/to/project/bin/[entry points]' and
> './ab
On 2 December 2013 13:38, Tres Seaver wrote:
> On 12/01/2013 06:38 PM, Paul Moore wrote:
>> I understand that things are different in the Unix world, but to be
>> blunt why should Windows users care?
>
> You're kidding, right? 90% or more of the reason for wheels in th
On 2 December 2013 14:19, Oscar Benjamin wrote:
> Basically if
> 1) There is at least one single consistent set of built wheels for
> Windows/OSX for any popular set of binary-interdependent packages.
> 2) A way to automatically detect incompatibilities and to
> automatically find compatible built
On 2 December 2013 15:28, Imran M Yousuf wrote:
> Thanks for the suggestion Paul. Wheel structures exactly as I want it
> to be, but I see it does not generate the entry point scripts; any
> idea how to get them to work?
The scripts should be generated when you install the wheel (with pip
1.5, wh
On 2 December 2013 22:26, Nick Coghlan wrote:
>>Whether solving the Unix
>> issues is worth it is the Unix users' call - I'll help solve the
>> issues, if they choose to, but I won't support abandoning the existing
>> Windows solution just because it can't be extended to cater for Unix
>> as well.
On 3 December 2013 08:41, Michael Jansen wrote:
> So another idea i am thinking about is doing it like this:
>
>
>
> scripts = [
>
> "bin/myscript3", # <= backwardscompatible
>
> ( 'bin/', [ 'bin/myscript1', 'bin/myscript2' ] ),
>
> ( 'sbin/', [ 'sbin/mysbinscript1', 'sbin/mysbinscript2' ] ),
>
>
On 3 December 2013 08:48, Nick Coghlan wrote:
>> And wouldn't it be better to make wheel a bit more robust in this regard
>> than add yet another recommended tool to the mix?
>
> Software that works today is generally more useful to end users than
> software that might possibly handle their use ca
On 3 December 2013 08:48, Nick Coghlan wrote:
> This means that one key reason I want to recommend it for the cases where it
> is a good fit (i.e. the scientific Python stack) is so we can explicitly
> advise *against* using it in other cases where it will just add complexity
> without adding valu
On 3 December 2013 09:11, Paul Moore wrote:
> On 3 December 2013 08:48, Nick Coghlan wrote:
>>> And wouldn't it be better to make wheel a bit more robust in this regard
>>> than add yet another recommended tool to the mix?
>>
>> Software that works today
On 3 December 2013 09:38, Michael Jansen wrote:
> So who will decide if any change to distutils goes through? I have no idea
> about the python patch process. Any links?
Patches can be posted on http://bugs.python.org. But generally,
changes to distutils are hard to get through so be prepared for
On 3 December 2013 10:36, Oscar Benjamin wrote:
> Perhaps it would help if there were wheels for conda and its
> dependencies.
That may well be a good idea. One thing pip does is go to great
lengths to *not* have any dependencies (by vendoring everything it
needs, and relying only on pure Python
On 3 December 2013 11:27, Thomas Heller wrote:
> Am 03.12.2013 09:56, schrieb Paul Moore:
>
>>
>> The "scripts" argument is generally considered obsolete - tools like
>> pip will not generate executable wrappers for scripts specified like
>> this, which m
On 3 December 2013 21:34, Marcus Smith wrote:
>> Anoconda (the distribution seems to address this by having conda packages
>> that are essentially containers for the shared libs, and other packages that
>> need those libs depend on them. I like this method, but it seems to me to be
>> more a feat
On 3 December 2013 21:34, Marcus Smith wrote:
>> The IPython web site makes it look like you really need to go get Anaconda
>> or Canopy if you want iPython
>
> interesting...
You really don't. I've been running IPython on Windows from wheels for
ages. And you can actually build from source easil
On 3 December 2013 22:18, Chris Barker wrote:
>> Looks like the conda stack is built around msvcr90, whereas python.org
>> Python 3.3 is built around msvcr100.
>> So conda is not interoperable *at all* with standard python.org Python
>> 3.3 on Windows :-(
>
> again, Anaconda the distribution, is
On 4 December 2013 07:40, Ralf Gommers wrote:
>> I’m not sure what the diff between the current state and what
>> they need to be are but if someone spells it out (I’ve only just skimmed
>> your last email so perhaps it’s contained in that!) I’ll do the arguing
>> for it. I
>> just need someone wh
On 4 December 2013 08:13, Paul Moore wrote:
>> If this is too difficult at the moment, an easier (but much less important
>> one) would be to get the result of ``paver bdist_wininst_simple`` as a
>> wheel.
>
> That I will certainly look into. Simple answer is "wh
I'm trying to mirror the simple index (just the index, not the
referenced files) in order to do some queries on package availability.
I was planning on doing a simple "wget --timestamping --recursive
--level=1" but when I do, everything seems to be downloaded each time.
Does PyPI not set the last
On 4 December 2013 21:13, Ralf Gommers wrote:
> Besides the issues you mention, the problem is that it creates a single
> point of failure. I really appreciate everything Christoph does, but it's
> not appropriate as the default way to provide binary releases for a large
> number of projects. Ther
On 4 December 2013 23:31, Nick Coghlan wrote:
> Hmm, rather than adding complexity most folks don't need directly to the
> base wheel spec, here's a possible "multiwheel" notion - embed multiple
> wheels with different names inside the multiwheel, along with a
> self-contained selector function fo
On 5 December 2013 09:52, Nick Coghlan wrote:
>> I'm not sure how this would work - wheels don't seem to me to be
>> appropriate for installing "external dependencies", but as I'm not
>> 100% clear on what you mean by that term I may be misunderstanding.
>> Can you provide a concrete example?
>
>
On 7 December 2013 08:19, Nick Coghlan wrote:
> That means that you can ship relatively arbitrary software in a wheel
> file by dumping it in "{distribution}-{version}.data/data/", and
> then installing it to the appropriate target location (e.g. if you use
> FHS paths inside the data directory, t
On 7 December 2013 10:12, Michael Jansen wrote:
>> I made a proof of concept implementation (not ready to be merged) here
>
> No one interested in that? Got no answer from the maintainers too.
Personally, I'm against the idea on principle, because the bin/sbin
distinction is not a cross-platform
On 7 December 2013 11:10, Michael Jansen wrote:
> I guess we agree here. But people already do that because they have no other
> choice. Nick only wants to document the way it works better. Many people
> already figured this out and use it anyway.
I believe it's an "attractive nuisance" and shoul
On 7 December 2013 11:14, Michael Jansen wrote:
> And then setting those variables in cross platform compatible ways.
Well, OK, but there may not *be* a "cross platform compatible" answer
- we could set sbin to the same as bin on Windows, but www is probably
inside the Apache installation (or som
I really don't have all the answers here, but...
On 7 December 2013 12:30, Michael Jansen wrote:
> So you consider anything that has parts that need to be installed into/under
> a web server as not windows compatible?
Not at all. If you're talking about documents, what's to "install"?
Just ask t
On 7 December 2013 13:45, Michael Jansen wrote:
> Anyway. You are at least willing to discuss with me. So thanks.
No problem! I hope I wasn't too discouraging - I get the impression
that I was :-(
My problem is that I don't know the answers on Windows, I only really
know enough to know when some
On 7 December 2013 16:56, Michael Jansen wrote:
> A windows developer should not care about the difference. Both end up in the
> same directory. [...] will one day get a bug report/patch from a unix user
OK, cool. That makes sense.
Paul
___
Distutils-SI
On 7 December 2013 21:32, Marcus Smith wrote:
> actually, bdist_wheel doesn't handle absolute paths in the "data_files"
> keyword like standard setuptools installs do, which honor it as absolute
> (which seems to match the examples in the distutils docs)
> when using absolute paths, the data ends
On 8 December 2013 02:01, Nick Coghlan wrote:
>> Maybe what we want is a sysconfig path "root" that explicitly encodes
>> the filesystem root.
>
> s/filesystem root/installation root/
>
> I'm assuming that's what you meant, since you'd know better than I do
> that "filesystem root" isn't a particu
On 12 December 2013 10:43, Bohuslav Kabrda wrote:
> Hey all,
> so I noticed a strange thing in RECORD of an installed wheel:
> When a wheel that contains file "foo-1.data/scripts/spam" is installed,
> "spam" gets copied to a proper dir (e.g. /usr/bin) and the whole "foo-1.data"
> directory is de
On 21 December 2013 10:57, Nick Coghlan wrote:
> And these are the generic directories that aren't necessarily Python specific:
>
> scripts: directory for script files.
> data: directory for data files.
It's worth noting that "data", although in essence a platform neutral
term, is in prac
On 23 December 2013 20:53, Chris Barker wrote:
> then you explicitly put in "bin", sbin", "share", whatever?
>
> This seems really klunky to me, and also forces platform dependence, and is
> fundamentally tied to how posix does things
>
> Maybe it's not possible, but I suggest that we could pr
On 28 December 2013 06:17, Nick Coghlan wrote:
> The other main thing to look at in terms of current state of the art
> is npm, for both structure and hooks.
Another place to look would be existing usage in distributions on
PyPI. I know that Vinay has done some work on extracting build-time
data
On 31 December 2013 22:53, Marcus Smith wrote:
> for #1, during installation, I imagine the new setuptools would build the
> sdist (and any entry_point declarations) using 2.0 metadata.
So assuming the package consuming the entry point converts to using
metadata 2.0 APIs (and does *not* try to ha
I'm writing an application to maintain a mirror of PyPI package
metadata, and I'm trying to understand the changelog data. In
particular, I've not been able to find anything that lists the valid
values for the "action" element of a change record. Looking at what's
available if I just query the data
701 - 800 of 1502 matches
Mail list logo
