earlier release, but supporting code wasn't removed until now).
A more detailed change log is available at [2].
Please try it out, and if you find any problems or have any suggestions for
improvements,
please give some feedback using the issue tracker! [3]
Regards,
Vinay Sajip
[1] htt
tailed change log is available at [2].
Please try it out, and if you find any problems or have any suggestions for
improvements,
please give some feedback using the issue tracker! [3]
Regards,
Vinay Sajip
[1] https://pypi.org/project/distlib/0.3.3/
[2] https://distlib.readthedocs.io/en/0.3
and if you find any problems or have any suggestions for
improvements,
please give some feedback using the issue tracker! [3]
Regards,
Vinay Sajip
[1] https://pypi.org/project/distlib/0.3.2/
[2] https://distlib.readthedocs.io/en/0.3.2/
[3] https://bitbucket.org/pypa/distlib/issues/new
--
Distut
dress bar - that should work.
Regards,
Vinay Sajip
[1] https://pypi.org/project/distlib/0.3.1/
[2] https://distlib.readthedocs.io/en/0.3.1/
[3] https://bitbucket.org/pypa/distlib/issues/new
--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-s
FYI distlib has moved to Git, while remaining on BitBucket. The move was made
in January 2020.
https://bitbucket.org/pypa/distlib/src/master/
Regards,
Vinay Sajip
On Tuesday, 16 June 2020, 03:45:52 BST, distutils-sig-requ...@python.org
wrote:
Send Distutils-SIG mailing list
X and Y are single digits).
A more detailed change log is available at [2].
Please try it out, and if you find any problems or have any suggestions for
improvements,please give some feedback using the issue tracker! [3]
Regards,
Vinay Sajip
[1] https://pypi.org/project/distlib/0.3.0/[2]
https:/
uggestions for
improvements,please give some feedback using the issue tracker! [3]
Regards,
Vinay Sajip
[1] https://pypi.org/project/distlib/0.2.9/[2]
https://distlib.readthedocs.io/en/latest/overview.html#change-log-for-distlib[3]
https://bitbucket.org/pypa/distlib/issues/new
--
Distutil
find any problems or have any suggestions for
improvements,please give some feedback using the issue tracker! [3]
Regards,
Vinay Sajip
[1] https://pypi.org/project/distlib/0.2.8/[2] https://goo.gl/tVzKUc[3]
https://bitbucket.org/pypa/distlib/issues/new--
Distutils-SIG mailing list -- distutil
. When setup is imported from distutils.core, the custom command class
is invoked.
What's the reason for the disparity - can someone please enlighten me?
Regards,
Vinay Sajip--
Distutils-SIG mailing list -- distutils-sig@python.org
To unsubscribe send an email to distutils-sig-le...@python.org
HIT,
MISSX-Cache-Hits: 1, 0X-Timer: S1528903221.367847,VS0,VE80Vary:
Accept-Encoding, Accept-EncodingStrict-Transport-Security: max-age=31536000;
includeSubDomains; preloadX-Frame-Options: denyX-XSS-Protection: 1;
mode=blockX-Content-Type-Options: nosniffX-Permitted-Cross-Domain-Policies: n
s also wrongly picking up 0.4.2. What's the expected delay
between uploading a new version and having it be available via pip? I would
have expected more or less immediately. All systems are showing as operational.
Regards,
Vinay Sajip
--
Distutils-SIG mailing list -- distutils-sig@py
f you find any problems or have any suggestions for
improvements,
please give some feedback using the issue tracker! [3]
Regards,
Vinay Sajip
[1] https://pypi.org/project/distlib/0.2.7/
[2] https://goo.gl/M3kQzR
[3] https://bitbucket.org/pypa/distlib/issue
at [2].
Please try it out, and if you find any problems or have any suggestions
forimprovements, please give some feedback using the issue tracker! [3]
Regards,
Vinay Sajip
[1] https://pypi.python.org/pypi/distlib/0.2.6[2] https://goo.gl/M3kQzR[3]
https://bitbucket.org/pypa/distlib/issue
or in scoring URLs for preferences.
* Removed Python 2.6 from the support list.
A more detailed change log is available at [2].
Please try it out, and if you find any problems or have any suggestions for
improvements, please give some feedback using the issue tracker! [3]
Regards,
Vinay Sajip
[1]
If the conversion function adds "Requires-Dist" but doesn't remove "Requires",
I'm not
sure it conforms to that version of the PEP.
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
, so that
nobody has to switch anything in a big-bang style, but could transition over to
a newer system
at their leisure.
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
kage
authors having to change anything (beyond staying purely declarative). The
distil
documentation [2] shows installing a number of distributions (existing
releases)
from PyPI with better dependency resolution than pip does now, and without
"throwing away
PyPI".
Anyway, I gues
more
incremental approach (which has got no new PEPs other than 440, AFAICT). I
understand that social reasons are often more important than technical reasons
when it comes to success or failure of an approach; I'm just not sure that
in this case, it wasn't given up on too earl
pip and
setuptools work, and because they are "good enough", there is a real failure of
imagination
to see how things might be done better.
Regards,
Vinay Sajip
[1] https://distil.readthedocs.io/en/0.1.0/overview.html#actual-improvements
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
> humpty in term uses uses distlib which seems to mishandle wheel> metadata.
>(For example, it chokes if there's extra distribution meta and
> makes it impossible for buildout to install python-dateutil from a wheel.)
I looked into the "mishandling". It's that the other tools don't adhere to [the
I accidentally cc-ed this list when sending email to a Python committer about
JetBrains licences. Please don't take up one of these licences unless you are a
Python committer; I will remove access from any person who is not named in
https://hg.python.org/committers.txt
I apologise for any confu
Dear Christian,
You can access the PyCharm and other JetBrains products licence at the
following link:
https://account.jetbrains.com/a/53fr5cnq
If you don't already have a JetBrains account, you will need to create one to
activate the licence.
Regards,
Vinay Sajip
at [2].
Please try it out, and if you find any problems or have any suggestions for
improvements, please give some feedback using the issue tracker! [3]
Regards,
Vinay Sajip
[1] https://pypi.python.org/pypi/distlib/0.2.4
[2] https://goo.gl/M3kQzR
[3] https://bitbucket.org/pypa/distlib/issue
ng the help /
documentation for it to better reflect what it does would be uncontroversial
for me, but I see no strong reason for deprecation and removal. As Paul
suggests, it can get stricter about what it'll handle.
Regards,
Vinay Sajip
__
at files.
A more detailed change log is available at [2].
Please try it out, and if you find any problems or have any suggestions for
improvements, please give some feedback using the issue tracker! [3]
Regards,
Vinay Sajip
[1] https://pypi.python.org/pypi/distlib/0.2.2
[2] https://goo.gl/M
om trying
out new approaches, it seems like the pace of development of better tools will
continue to be glacial.
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
on-empty list when passed "sarg" (matching my project "sarge"), or when
passed "jobswo" (matching my project "jobsworth"). My project "ragamuffin"
also fails to show up if passed to the script.
Can anyone shed any l
cased value.
Handled multiple-architecture wheel filenames correctly.
A more detailed change log is available at [2].
Please try it out, and if you find any problems or have any suggestions for
improvements, please give some feedback using the issue tracker! [3]
Regards,
Vinay Sajip
[1]
on and is not
always necessarily available for all different loader implementations - which
is perhaps why a `pkgutil.get_data_stream` is not provided.
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
From: Daniel Holth
> No, PEP 426 needs to be static metadata that is not modified by the installer.
> The new json file would make more sense in (a successor to) PEP 376 "Database
> of Installed Python Distributions".
Agreed. That's what I meant :-
not necessarily present in the wheel - is that right? If not
present in the wheel (or perhaps anyway) ISTM it makes sense to specify it in
PEP 426 because it's part of the installation metadata.
Regards,
Vinay Sajip
___
Distutils-
and line overrides
specified by a user at installation time).
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
alised parsing code would seem to be required.
Is your preference due to concerns about performance, aesthetics, backward
compatibility or something else?
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
the list of files installed. When you say "package's
namespace", are you referring to the .dist-info directory, or something else?
Those two words are fraught with ambiguity.
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutil
l work cross-platform? I'm bearing in mind that there might be
other implementations of installers which would need to interoperate with any
file category scheme ...
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
pence ...)
Regards,
Vinay Sajip
From: Steve Dower
To: Paul Moore ; Brian Cole
Cc: "distutils-sig@python.org"
Sent: Saturday, 18 April 2015, 15:46
Subject: Re: [Distutils] How to sign a exe created with bdist_wininst?
#yiv2682230560 #yiv2682230560 -- .yiv2682230560EmailQuote
{
From: Daniel Holth
> Vinay Sajip was maintaining metadata as described here, I'm sure there are
> functions
> in distil to help fetch it.
Yes, though there is no need for any special API to access it - the
metadata is in JSON files served statically. You just make a standar
, and if you find any problems or have any suggestions for
improvements, please give some feedback using the issue tracker! [3]
Regards,
Vinay Sajip
[1] https://pypi.python.org/pypi/distlib/0.2.0
[2] http://pythonhosted.org/distlib/overview.html#change-log-for-distlib
[3] https://bitbucket.org
AFAIK pip does use distlib (it is vendored by pip), but only for some ancillary
functions such as pre-release version checks.
I'm not sure it's a good idea to use pip's internal API (as it's internal, and
I don't believe it's been designed for use as a library by
are alternative tools
available (such as remmina).
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
> From: Steve Dower
> Microsoft has released a compiler package for Python 2.7
Great. Thank you very much! Downloading it now :-)
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/li
larative
metadata, while offering a migration path (which 3.3 packaging didn't). While
they're not perfect, distlib/distil allow me to install stuff without executing
setup.py on target systems a lot of the time, and ISTM that's
> Warehouse is currently focused on reimplementation with the future being
> standization and spec work for new stuff.
> Twine uses the same APIs as distutils does on PyPI, but it A) Verifies TLS
> and B) enables uploading an already built
> distribution instead of mandating that you build it
wer PEPs such as 426, 427, and 440.
Is there some particular functionality you need that distlib.version doesn't
provide?
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
ch as Warehouse or Twine -
are there any PEPs specifying anything new that they do over existing
PyPI/distutils, or is there nothing new over and above existing code other than
(no doubt improved) reimplementation of existing functionality?
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
should replace RECORD, etc. with JSON equivalents
(to be neat and tidy).
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
> PyPI won’t show metadata for Wheels either unless you upload them with Twine
Why is that, exactly? Is there something alternate tools would need to do to
achieve the same thing?
Regards,
Vinay Sajip
From: Donald Stufft
To: Daniel Holth
Cc: Brett Gra
to a point-and-click installer, without
using a command line? Drag-and-drop onto a venv folder is a possibility, but
that's not exactly the conventional usage idiom for MSIs.
Regards,
Vinay Sajip
From: M.-A. Lemburg
To: Python Distutils SIG
Sent: Monday, 7
inly possible that there are a few bugs lurking in my metadata "scraping"
code.
The code doesn't do anything clever like aliasing PIL/Pillow or
distribute/setuptools - it's the bare dependencies as declared in zillions of
setup.py files.
Regards,
Vinay Sajip
__
rojects declare things as run-time dependencies when
they really mean build-time: I'm not sure that there are really over 400
projects which are Sphinx plugins / extensions.
Just throwing this out there as it may be of interest.
Regards,
Vinay Sajip
___
From: Daniel Holth
> Just build a wheel first. Then numpy is installed twice but only built once.
Isn't that just papering over the cracks?
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.py
give some feedback using the issue tracker! [3]
Regards,
Vinay Sajip
[1] https://pypi.python.org/pypi/distlib/0.1.9
[2] http://pythonhosted.org/distlib/overview.html#change-log-for-distlib
[3] https://bitbucket.org/pypa/distlib/issues/new
___
Distutil
pproach that distil uses is good enough. Of course, more complex /
important packages are exceptions, and would need more work (corresponding to
their complexity) to fit into a declarative approach.
Regards,
Vinay Sajip
___
Distutils-SIG maillist - D
eases -
it's just that the setup.py scheme is a bit archaic and not entirely
problem-free.
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
functionality, as that needs more attention than the
installer/uninstaller functionality. I've been meaning to address some items
relating to PEP 426, but unfortunately time has been in shorter supply than it
is usually :-(
Regards,
Vinay Sajip
__
> That would be the == in "requires": ["SoftCushions == 4"] which IIUC
> in the current PEP would be allowed in meta_ but disallowed in
> run_requirements.
Okay, I see it now. Thanks.
Regards,
Vinay Sajip
___
Distutils-S
;], "extra": "warmup" }
]
where each dictionary in the list could have "requires", "extra" and
"environment" keys. The "environment" value might have "==" as part of a marker
expression. Are you talking about something el
may not match what's
expected, as per the original installation).
To avoid overwriting, one would need to write versioned scripts *only* :-)
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/
bstractions used in distutils / setuptools), distil's approach focuses on
a command line with variable placeholders - this allows just about anything
to be plugged in for custom builds. There's still work to be done on it, but
the initial approach
> 1. Formally decouple the setup.py CLI from the distutils command system
Agreed - it looks like a compatible CLI needs to be part of the transition
to any new system (I assume that's what you meant).
Regards,
Vinay Sajip
___
Distutils-SIG
be a *completely* arbitrary-code process. I
understand well that user-defined code should be accommodated, but IMO this
should be within a declarative framework with well-defined hooks, otherwise it
will ultimately lead to the same problems that setup.py has.
Rega
and
without using distutils or setuptools.
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
lease try it out, and
if you find any problems or have any suggestions for improvements, please
give some feedback using the issue tracker! [3]
Regards,
Vinay Sajip
[1] https://pypi.python.org/pypi/distlib/0.1.8
[2] http://pythonhosted.org/distlib/overview.html#change-log-for-distlib
[3]
From:Michael Bayer
> OK so why does PEP-426 compatibility imply removal of command line switches
> from setup.py files ?
As far as I know, it doesn't. My distil tools complies with a fairly recent
version of PEP 426 and AFAIK has no problem building / installing SQLAlchemy
with / without
n would e.g.
SQLAlchemy specify that an older setuptools version should be used? Would pip
downgrade the venv's setuptools to an older version? Even if it did, might
that not break other distributions in the venv?
Regards,
Vinay Sajip
___
Distut
rce
distributions (there will be another PEP covering that).
Apart from the most recent changes being not yet implemented and some open
issues relating to hooks, PEP 426 seems to cover installation metadata
reasonably well. However, sdist metadata is a different kettle of fish.
Reg
> There is always going to be multiple files, it’s kind of silly to tie the
> definition of
> the dist-info directory to the pydist.json when that’s perhaps not the file
> you
> care about how to interpret. How do you interpret the RECORD file?
> The INSTALLER file?
> The versioned definition
re added on top of the 1.2 metadata in an
early version of PEP 426, before the move to JSON.
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig__
> PEP 425 explicitly covers that.
It says "The version is py_version_nodot. CPython gets away with no dot, but if
one is needed the underscore _ is used instead. PyPy should probably use its
own versions here pp18, pp19".
The "probably" leaves some room for doubt as to what exactly is meant:
> It makes perfect sense to version the dist-info directory.
> You don’t know how to interpret the files inside that directory without it.
> You have to rely on heuristics and guessing.
Not if you specify up front how it will work, which is doable.
It's not clear to me if you mean putting the
> If Vinay is happy with that last option for handling the current bdist_wheel
>misbehaviour
> that would mean we could leave the metadata version alone
I've changed distlib to ignore pydist.json for wheels with version 1.0, where
METADATA is used instead. Note that bdist_wheel also puts a metad
or "license" for more information.
>>> import sysconfig; print(sysconfig.get_path('scripts'))
/usr/local/bin
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
dback from anyone
regarding specific failures of distil in terms of practical
workflows that aren't possible. "Doesn't need to be
installed in a venv" or "runs as a single file" isn't a failure from
my POV, so we'll have to agree to disagree.
But, as you say,
ely asked for a hearing, and made no claims I couldn't
substantiate, and with actual code in places. But you seem
determined not to give me that hearing, so I'll drop it. It's a
shame you have to resort to an argument from authority.
Regards,
Vinay Sajip
___
otherwise?
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
nsuring" being necessary. So from what I can see, your
argument is based on an imperfect understanding of how distil
works. If you'd like to understand it better I'll provide the support,
but if you don't want to or can't do that - well, that's a shame, but
such is life :-)
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
It's hard to argue against voodoo, but anyone on this list
could put me right with a particular circumstance that I haven't
thought of, but that they have run into, which undermines my
argument. It's not uncommon to see the "well ... we're not q
ntioned
before) that illustrate that goodness versus the badness of
other approaches.
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
rading /
uninstallation of packages in a venv and Y is something which
intrinsically arises from the installation tool not being installed in the
venv. That would certainly help me understand where you're coming
from.
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
st of the logic in the restarted program
is run, so a question like "why didn't restart_in_venv get called, when it
should have been?" doesn't arise. There are no rabbit-holes to go down. The
approach in that snippet could apply to any script - it's not esp
bout aesthetics in my view, but I don't regard these sorts
of arguments as "religious". If "religion" is to be mentioned in connection
with pip, then perhaps it's fair to say that pip is the "sacred cow" of Python
packaging ;-)
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
o copy in-zip resources to the file system will
be around for quite some time.
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
linked to in my original post.
So, it doesn't seem all that clear cut ... I suppose it depends on the
jurisdiction, too.
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
deployment means having a comprehensive license statement is
tricky, but I will think on it.
Not that it makes a difference to you, of course, but thanks for pointing
it out.
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@
other Python APIs which need a pathname - I know
imp.load_dynamic() will be familiar to you :-)
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
ints and AFAIK you can't use them for files. Plus, what Paul said about
the elevation issues (not a factor for XP, I know, but would need to be
taken into account for any solution across multiple Windows versions).
Regards,
Vinay Sajip
___
Dis
of the pkgutil gaps I referred to in my reply to Brett,
which pkg_resources and distlib.resources both address.
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
gt; for reading intra-package "files".
+1
> Maybe the Packaging Users Guide could have a
> Recommended Deployment Strategies section
[...]
> (especially if the instructions work on all platforms, i.e. no
> symlink discussions)
+1 again.
Regards,
Vinay Sajip
an
> OSS license that pip wouldn’t have used it
Sure, but I assume it wasn't used *just* because of the license. It
has to be useful in some way too.
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
ribe to the idea that
somehow everything magically gets better when it's put on GitHub.
Note that distlib is licensed under a valid OSS license, but it hasn't
made much difference in terms of the amount of feedback I've
received.
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
didn't just try or think of this, it did and it ultimately removed
> it.
Sure, and if they did find some problem which is also present in
distil (i.e. due to a fundamental drawback of the approach) then I'll put
my thinking cap back on. It'll be worth ha
27;m somehow trying to bring something *new* to the
discussion *now*. I certainly made my reservations about the pip-
bundling route at the time it was being discussed here, but if
nobody was willing to look at alternatives, it's not something I
could help.
Of course, once the decision is mad
lem of having a newer or older pip in a venv
only exists because pip needs to be in a venv ... so I don't see
the relevance of this to our earlier discussion. Since distil
doesn't occupy a space in venvs,. the concern of a system
version being older or newer than that in a venv doesn't
development when
I can, and I feel their presence more in the pip project than I'm
comfortable with. I don't really want to fight non-technical battles.
Re. PEP 453, I voiced my reservations at the time, but if "that ship
has sailed", then so be it - "nobody ever got fired for recommending
pip". The Python community will get the packaging infrastructure that
it deserves, just like a populace does with elections :-)
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
eal with building
wheels from sdists. They could be relatively easily merged
into an install command that works like pip, but I thought the
point was to separate building from installation, so that's why
distil is like it is at the moment.
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
tunted version called "reparse points" or "junction points" which are
not really fit for purpose. I think you'll find that XP environments are found
in rather more than "a tiny number of cases", and even though Microsoft
has end-of-lifed XP in terms of support,
t; compatible versions of packages to be shared between
> multiple virtual environments
Do you mean ref files, as discussed on import-sig?
Sure, but that's a tangential issue in my view. Worthwhile
pursuing, certainly, but an incremental improvement over what
ng any issue with installing into venvs, it's better to bundle pip and
setuptools
with Python 3.4, since that will seemingly be easier for people to swallow :-)
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
s that might not be common knowledge?
I certainly find single-file executables containing Python code a boon
and hope they play a bigger part in how Python software is distributed.
I will be looking into PEX for some good ideas :-)
Regards,
Vinay Sajip
e
that if/when such a capability becomes available on mainstream
platforms, the memimporter API could be adapted to cover it.
Regards,
Vinay Sajip
___
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig
1 - 100 of 501 matches
Mail list logo
