GSOC 20
Hello, I'm Pavitra, Pre-final year student of B.Tech - Computer Science & Engineering. I'm very much interested in contributing to MacPorts under GSOC 20. Kindly guide me on the How-Tos. A little bit about myself: I've been coding for approximately 7 years now and my primary domain used to be web development and backend development. But for past year or two, I'e switched to python and MacOs. Been using UNIX based systems for more than half a decade. Hoping to hear soon, Thank you, Pavitra Behre
Strange behaviour of subprocess_check_output with Macports Python in virtualenv
Hello,
I’m experiencing a problem (https://github.com/davidhalter/jedi/issues/1375).
Running this on a Python installed with Macports:
```
Python 3.8.1 (default, Feb 8 2020, 01:33:23)
[Clang 11.0.0 (clang-1100.0.33.16)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> subprocess.check_output('/Users/rubendibattista/.envs/josiepy-B4k-0ZyT/bin/python
>>> -c "import sys; print(sys.executable)"', shell=True)
b'/opt/local/bin/python\n'
```
I get as result the system python executable and not the one from the
virtualenv (created using pew).
While on Linux:
```
Python 3.7.3 (default, Jun 7 2019, 17:57:55)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-36)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import subprocess
>>> subprocess.check_output('/home/ruben.di-battista/.envs/josiepy/bin/python
>>> -c "import sys; print(sys.executable)"', shell=True)
b'/home/ruben.di-battista/.envs/josiepy/bin/python\n'
```
Does it work for you? Is it a bug from Macports, from my particular
configuration, from macOs or from Python build on macOs? (Or isn’t a bug?)
_
-. .´ |
', ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
.' '. |
-' `’
https://rdb.is
signature.asc
Description: Message signed with OpenPGP using AMPGpg
Re: Packaging py-keyring
> I must say I am also not convinced we actually need to add another Python > package manager, but perhaps there are use-cases I haven’t considered yet. I > would say that if you want to use MacPorts to take care of you Python > package, use it to handle your dependencies. If you want to use poetry to do > so, you likely want to install it in their recommended way (i.e., "isolated > from the rest of your system by vendorizing its dependencies” [1]) and don’t > need MacPorts for that. Pipenv is already in MacPorts (with 10 requested installs on MacPorts stats and only two of those are me!) and it does the same sort of job as Poetry does. I would be shocked if one was allowed in and another wasn't, and if you're seriously considering banning Poetry you probably also want to remove Pipenv from distribution. Both programs are used on the command line to manage the virtualenv for your projects. Their code bases are fully independent of your Python codebase, there is no `import poetry` or anything like that. The recommended Poetry installation is a great, pragmatic choice for newbies unfamiliar with good system administration practice - it gets them a quick, working installation that is unlikely to break on them. However, it is has the tradeoff that you now have a separate installation of Python software somewhere on your system, unmaintained and forgotten. The philosophy behind package managers like MacPorts is to avoid that situation entirely: everything installed on a system should be registered centrally to allow for easy installation, removal and timely software and security updates for the entire dependency graph. It's not wrong for Poetry's README to suggest what it does but Poetry definitely has a home in MacPorts. tl;dr Poetry exists outside of your software projects. It is installed and used globally and it makes sense to use MacPorts to manage Poetry like it does to use MacPorts for all the other globally installed software on your system. The fear with patching Poetry's setup.py to support post-v20 releases of py-keyring is that keyring's maintainers might chose to make hard, breaking, backwards-incompatible choices like `from __future__ import annotations` that would totally wreck compatibility with old releases of Python. However, if the MacPorts policy is to not to match Poetry's support for older Python 3.x releases the risk of that happening goes way down to the point where I'd be surprised if it is ever an issue. And finally the keyring API has only five functions. If there was a serious API-incompatible change to those you'll probably be packaging a keyring2 or doing something else to deal with the fallout across everything that depends on keyring anyway and Poetry will piggyback on whatever you do for that. -- David Gilman :DG<
Re: right way to add a library to src/
> Without taking a closer look, I think there is only one other file that is > shared between darwintrace and pextlib. Unfortunately, there is no good > solution > to this in the current structure. What it currently does is to copy the > *.c file > around during compilation, but I think this is a really horrible > workaround. > I think the better option would be to have a new subdirectory for a > library with > the shared code that is then linked (statically) into both darwintrace and > pextlib. > Yes, doing that with a static library was the final solution. Meanwhile, I tried many ways to somehow get it working using a shared library, maybe because with shared lib things were much clean and compact. But the issue was darwintrace code would intercept sys calls in our shared library as well which would make things even more complicated and slower. Thanks, Mihir
