As a user, I’d much rather report a rare package that doesn’t work than the
current situation in which hundreds or more of dependencies are unavailable in
MacPorts and I have to go through the process of updating Portfiles by hand or
managing the pip installs.
A major reason that many Python p
On Mar 2, 2021, at 09:25, Steven Smith wrote:
> The approach of other Python package managers (conda, pip) is to simply use
> whatever the installed version is and presume that the package will build and
> work. If it doesn’t, post an issue.
>
> Currently, keeping MacPorts Python ports up-to
The approach of other Python package managers (conda, pip) is to simply use
whatever the installed version is and presume that the package will build and
work. If it doesn’t, post an issue.
Currently, keeping MacPorts Python ports up-to-date requires hand editing every
single Portfile, committi
On Tue, 2 Mar 2021 at 11:21, Ryan Schmidt wrote:
> On Mar 1, 2021, at 09:49, Joshua Root wrote:
>
> > Once that's done, there's no problem adding lots of them in a single commit.
>
> It can be difficult to get approval from a large number of maintainers for a
> single PR. If you're going to submi
On Mar 1, 2021, at 09:49, Joshua Root wrote:
> Once that's done, there's no problem adding lots of them in a single commit.
It can be difficult to get approval from a large number of maintainers for a
single PR. If you're going to submit a PR that does a mass update for this that
affects por
On 2021-3-2 02:23 , Steven Smith wrote:
A very large number of Python ports don't exist in
${python.default_version} (py39).
Is there an efficient way to include these in MacPorts without all those
individual edits and commits?
I expect that most/all of these will simply work with
A very large number of Python ports don't exist in ${python.default_version}
(py39).
Is there an efficient way to include these in MacPorts without all those
individual edits and commits?
I expect that most/all of these will simply work with a 39 tacked on to
python.versions.
Here’s the
