Hello
I have a project with a fairly involved build process where we generate
C++ via a python-clang-based code analyser, generates Python bindings
for the resulting C++ API with SWIG, and finally compile and link to
create various .so's and .py files.
I'd like to package things up with a setup.py script, but from what i
have read, it looks like distutils expects to compile, link and run
swig itself, using distutils.core.setup()'s ext_modules arg?
Is there a way to write setup.py so that it instead runs an external
command (e.g. 'cd foo && make all') when it is asked to build?
Thanks for any help,
- Jules
--
http://op59.net
Good news!
New York University -- specifically Professor Justin Cappos -- and I
have successfully asked the US National Science Foundation for a grant
to improve Python packaging security. The NSF is awarding NYU $800,000
over two years -- from mid-2021 to mid-2023 -- to further improve the
pip dependency resolver and to integrate The Update Framework further
into the packaging toolchain.
https://nsf.gov/awardsearch/showAward?AWD_ID=2054692&HistoricalAwards=false
For what we're planning to do, what this means in the short term, an
explanation of why NYU and the NSF are involved, and thank-yous, please
see https://discuss.python.org/t/new-packaging-security-funding-nyu/7792 .
--
Sumana Harihareswara
Changeset Consulting
https://changeset.nyc
Not sure exactly what broke in the chain of my toolset for building reportlab. I have a github action which fails with
the message
ls: cannot access /opt/python/cp27-cp27mu/bin: No such file or directory
so because I have fixed the checkout version of the multibuild area itself I suppose that something else changed/updated
since the last build which was successful on Jan 22.
has multibuild / manylinux decided to abandon the python 2.7 version or is there something I can do to get my builds
going again?
As an aside is it worth trying to fix the version of multibuild or should I just assume that most of the variability
will come from the many docker layers that seem to be used.
> Digest: sha256:efc8a9832a07678fc17026ab35aa6444c02a665ccd5e6552c90d036045d78b17
> Status: Downloaded newer image for quay.io/pypa/manylinux2010_x86_64:latest
> + break
> quay.io/pypa/manylinux2010_x86_64:latest
> + '[' 5 -eq 0 ']'
> + return 0
> + docker run --rm -e 'BUILD_COMMANDS=build_wheel reportlab' -e PYTHON_VERSION=2.7 -e MB_PYTHON_VERSION=2.7 -e UNICODE_WIDTH=32 -e BUILD_COMMIT=HEAD -e CONFIG_PATH=.travis-config.sh -e ENV_VARS_PATH= -e WHEEL_SDIR=wheelhouse -e MANYLINUX_URL= -e BUILD_DEPENDS= -e USE_CCACHE= -e REPO_DIR=reportlab -e PLAT=x86_64 -e MB_ML_VER=2010 -v /home/runner/work/reportlab-mirror/reportlab-mirror:/io -v /home/runner:/parent-home quay.io/pypa/manylinux2010_x86_64 /io/multibuild/docker_build_wrap.sh
> ls: cannot access /opt/python/cp27-cp27mu/bin: No such file or directory
> Error: Process completed with exit code 2.
--
Robin Becker
Thanks Jeremy, I will check those out. I thought that maybe there was a
simple flag I could pass in to python -m build that would allow me to
override a value in setup.cfg, but I should probably read through
PEP517/PEP518 in full to get a better overview of this process.
>
>
> From: Jeremy Stanley <fungi(a)yuggoth.org>
> Date: Tue, Feb 9, 2021 at 3:26 PM
> Subject: [Distutils] Re: Building Pre-releases with setup.cfg
> To: <distutils-sig(a)python.org>
>
>
> On 2021-02-09 09:48:31 -0500 (-0500), Matthew Gilbert wrote:
> > I'm wondering if it is possibly to build pre-release tags using only a
> > setup.cfg file? From
> >
> https://setuptools.readthedocs.io/en/latest/userguide/distribution.html#tag…
> > it seems like this is possible via setup.py, but I was unable to find
> > anything related to setup.cfg.
> [...]
> > Possibly this can be configured using the --config-setting flag but I
> have
> > been unable to get this to work or find any documentation on it. Ideally
> I
> > would be able to pass a string so I can build a dev version for testing
> > uploads to Test PyPI, e.g. "0.0.1devHASH"
> [...]
>
> I'm probably misunderstanding your question, but typically I've seen
> something like PBR or Setuptools-SCM used to automatically calculate
> the version at dist build time (including inferring something based
> on the number of commits on the branch since the last tag, embedding
> abbreviated Git commit IDs, or whatever).
> --
> Jeremy Stanley
> --
> Distutils-SIG mailing list -- distutils-sig(a)python.org
> To unsubscribe send an email to distutils-sig-leave(a)python.org
> https://mail.python.org/mailman3/lists/distutils-sig.python.org/
> Message archived at
> https://mail.python.org/archives/list/distutils-sig@python.org/message/PUAS…
>
Hi all,
I'm wondering if it is possibly to build pre-release tags using only a
setup.cfg file? From
https://setuptools.readthedocs.io/en/latest/userguide/distribution.html#tag…
it seems like this is possible via setup.py, but I was unable to find
anything related to setup.cfg. An abridged version of my setup.cfg file
looks like
[metadata]
name = tester_project
version = attr: tester_project.__version__
[bdist_wheel]
universal=1
[build-system]
requires =
setuptools >= 40.9.0
wheel
build-backend = setuptools.build_meta
Which I was building using
$ python -m build --sdist --wheel --outdir dist
Possibly this can be configured using the --config-setting flag but I have
been unable to get this to work or find any documentation on it. Ideally I
would be able to pass a string so I can build a dev version for testing
uploads to Test PyPI, e.g. "0.0.1devHASH"
Any info or references is much appreciated!
Thanks,
Matt
Good afternoon,
I am trying to find out if there are any end-of-life versions for
Python-Setuptools, and if so, when do these versions typically become
EOL/unsupported? If this information is publicly stored anywhere please let
me know. Thanks.
Hi everyone,
https://setuptools.readthedocs.io/en/latest/deprecated/easy_install.html instructed me that the mailing list would like to know any use cases where Easy_install is felt needed and I believe I have one. and I do not see any posts about this specific use case.
AWS Glue is a serverless runtime environment offered by AWS, usually it runs Spark jobs but Jan 22, 2019 they released Python Shells to run quick snippet codes. they have a fairly comprehensive list of preinstalled libraries and allow you to specify wheels and eggs for anything additional stored on an S3 that you would need, with one limitation - no C-extensions, Cython wheels cannot be installed.
for my use-case I needed to access some SFTPs but Paramiko depends on cryptography for SSH shenanigans and cryptography (along with its dependencies cffi, PyNaCL, and bcrypt) are CPython.
Turns out if you install at runtime there is no issue - it's just with initial setup that has the limitation. of course you then have to install every time that a process runs during paid runtime, rather than startup but better that then not at all.
I tried 2 approaches to install at runtime: subprocess.call(['pip' ...]) and setuptools.command.easy_install.main()
subprocess.call to pip installs pure python very nicely, but every time it hit a CPython wheel/tarball - CFFI, PyNaCl, bcrypt, cryptography, and paramiko - took 6-7 minutes EACH just to install (files were provided locally, downloaded from the S3 from previous attempt seeing what would happen if you just gave it CPython )
In a separate run setuptools...easy_install processed everything in 2 seconds. Somewhere between pkg_resources.getdistribution('paramiko').activate(), importing them, and setting host keys lead to Main process starting a little less than 2 minutes later.
Required use-case? Not technically
Fringe use-case? Fairly
Appreciated that this is still around? Very much, 2-minute startup runtime is appreciated over upwards of half an hour on every single run.
On behalf of the PyPA and the pip team, I am pleased to announce that we
have just released pip 20.3, a new version of pip. You can install it by
running `python -m pip install --upgrade pip`.
[Cross-posted to
https://discuss.python.org/t/announcement-pip-20-3-release/5948 which
will be easier to read in a web browser and to link to.]
This is an important and disruptive release -- we [explained why in a
blog post last
year](https://pyfound.blogspot.com/2019/12/moss-czi-support-pip.html). We
even made [a video about
it](https://www.youtube.com/watch?v=B4GQCBBsuNU).
## Highlights
* **DISRUPTION**: Switch to the new dependency resolver by
default. (#9019) Watch out for changes in handling editable
installs, constraints files, and more:
https://pip.pypa.io/en/latest/user_guide/#changes-to-the-pip-dependency-res…
* **DEPRECATION**: Deprecate support for Python 3.5 (to be removed in
pip 21.0) (#8181)
* **DEPRECATION**: pip freeze will stop filtering the pip, setuptools,
distribute and wheel packages from pip freeze output in a future
version. To keep the previous behavior, users should use the new
`--exclude` option. (#4256)
* Substantial improvements in new resolver for performance, output and
error messages, avoiding infinite loops, and support for constraints
files.
* Support for PEP 600: Future ‘manylinux’ Platform Tags for Portable
Linux Built Distributions. (#9077)
* Documentation improvements: Resolver migration guide, quickstart
guide, and new documentation theme.
* Add support for MacOS Big Sur compatibility tags. (#9138)
The new resolver is now *on by default*. It is significantly stricter
and more consistent when it receives incompatible instructions, and
reduces support for certain kinds of constraints files, so some
workarounds and workflows may break. Please see [our guide on how to
test and migrate, and how to report
issues](https://pip.pypa.io/en/latest/user_guide/#changes-to-the-pip-dependency-resolver-in-20-3-2020).
You
can use the deprecated (old) resolver, using the flag
`--use-deprecated=legacy-resolver`, until we remove it in the pip 21.0
release in January 2021.
You can find more details (including deprecations and removals) [in the
changelog](https://pip.pypa.io/en/stable/news/).
## User experience
Command-line output for this version of pip, and documentation to help
with errors, is significantly better, because you worked with our
experts to test and improve it. [Contribute to our user experience work:
sign up to become a member of the UX Studies
group](https://bit.ly/pip-ux-studies) (after you join, we'll notify you
about future UX surveys and interviews).
## What to expect in 20.1
We aim to release pip 20.1 in January 2021, per our [usual release
cadence](https://pip.pypa.io/en/latest/development/release-process/#release-cadence).
You can expect:
* Removal of [Python
2.7](https://pip.pypa.io/en/latest/development/release-process/#python-2-support)
and 3.5 support
* Further improvements in the new resolver
* Removal of legacy resolver support
## Thanks
As with all pip releases, a significant amount of the work was
contributed by pip's user community. Huge thanks to all who have
contributed, whether through code, documentation, issue reports and/or
discussion. Your help keeps pip improving, and is hugely appreciated.
Specific thanks go to Mozilla (through its [Mozilla Open Source
Support](https://www.mozilla.org/en-US/moss/) Awards) and to the [Chan
Zuckerberg Initiative](https://chanzuckerberg.com/eoss/) DAF, an
advised fund of Silicon Valley Community Foundation, for their funding
that enabled substantial work on the new resolver.
That funding went to [Simply Secure](https://simplysecure.org/)
(specifically Georgia Bullen, Bernard Tyers, Nicole Harris, Ngọc
Triệu, and Karissa McKelvey), [Changeset
Consulting](https://changeset.nyc/) (Sumana Harihareswara),
[Atos](https://www.atos.net) (Paul F. Moore), [Tzu-ping
Chung](https://uranusjr.com), [Pradyun Gedam](https://pradyunsg.me/),
and Ilan Schnell. Thanks also to Ernest W. Durbin III at the Python
Software Foundation for liaising with the project.
--
Sumana Harihareswara, pip project manager
Changeset Consulting
https://changeset.nyc
Hello,
We were trying to create an automated installation process.
As part of this, our software deployment team has requested the installation instructions, which I was unable to locate.
Can you help by pointing me towards them?
Thank you,
Brian
Brian Cort | Application Analyst
Kroger Technology: Point of Sale | The Kroger Co.
office: 503.797.3229 cell: 971.293.6244
[cid:image001.png@01D6CD4D.01E06F70]
For more POS related information, please feel free to see our publicly accessible Wiki/Confluence Site:
https://confluence.kroger.com/confluence/x/BySXBQ
________________________________
This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain information that is confidential and protected by law from unauthorized disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.
