2 ms·

>That, in a nutshell, is the problem. That problem can be solved with money. I've seen Jessica McKellar offer to shower PSF money over people who want to help

>That, in a nutshell, is the problem. That problem can be solved with money. I've seen Jessica McKellar offer to shower PSF money over people who want to help make installation of python easier for beginners on Windows. I've not seen her offer to shower money over anybody wanting to solve this problem. And, as I mentioned before I don't believe a solution like that unixpackage would actually make it into pip. They'd refuse it. That, in the nutshell, is the problem. >There are good reasons it wouldn't make it into pip: something like that is more the realm of setuptools, rather than pip. Maybe. I'm never really sure where one ends and the other begins, to be honest. Perhaps that's part of the problem. >you're essentially proposing a parallel system package management system, I am, yes. And as ridiculous as that may sound it's utterly crucial. >and at that point you'd might as well just propose that the Python packaging toolchain integrate, I don't know, maybe pkgsrc into itself. That would be my other proposal, yes. Either pkgsrc, guix or nix. >Also, there is next to no chance of what you propose happening Want to know what's really shit about python?

talideon 10y ago
No, this is a significantly bigger problem than simply getting things to work well on Windows. Have you proposed this to anyone in the PSF? > Maybe. I'm never really sure where one ends and the other begins, to be honest. Perhaps that's part of the problem. In a nutshell, leaving out various details: pip downloads packages, asks them for their dependencies, downloads the dependencies, asks them for their dependencies, and so on, and so on. Then it does a topological sort and asks them to install themselves. The process of installation is done by the setup.py file within the package[1]. That's setuptools. The line between the two is pretty clear; this is similar to the split between dpkg/apt or rpm/yum, except setuptools itself has some built-in dependency resolution support. [1] Assuming it's not a wheel. > I am, yes. And as ridiculous as that may sound it's utterly crucial. And a security nightmare. > Want to know what's really shit about python? Do you know what's shit about dealing with just about every language out there? Pick a language with its own package management, and the moment it steps outside of its own runtime environment, this problem crops up. Want to know why I think there's little chance of this working? It's nothing to do with Python and everything to do this being a nightmare for sysadmins.
- crdoconnor 10y ago
  >Have you proposed this to anyone in the PSF? I'm not interested in getting involved in their politics. >And a security nightmare. Absurd. >Do you know what's shit about dealing with just about every language out there? Not this. You might have noticed a variety of java programmers saying "nope, not an issue here". >Pick a language with its own package management, and the moment it steps outside of its own runtime environment The issue is not at all to do with stepping outside of the runtime environment and everything to do with running code in an uncontrolled environment. The solution is to control the environment as much as you can and fail cleanly if you can't. >Want to know why I think there's little chance of this working? No, I have no interest in what you think any more.
  - talideon 10y ago
    > I'm not interested in getting involved in their politics. Then why did you even bring them up? > Absurd. Not if you're a sysadmin. > Not this. You might have noticed a variety of java programmers saying "nope, not an issue here". Because JNI is barely used. This isn't the case with Python, or Ruby, or a host of other lanuages. > No, I have no interest in what you think any more. Don't be an ass.

talideon 10y ago

No, this is a significantly bigger problem than simply getting things to work well on Windows. Have you proposed this to anyone in the PSF? > Maybe. I'm never really sure where one ends and the other begins, to be honest. Perhaps that's part of the problem. In a nutshell, leaving out various details: pip downloads packages, asks them for their dependencies, downloads the dependencies, asks them for their dependencies, and so on, and so on. Then it does a topological sort and asks them to install themselves. The process of installation is done by the setup.py file within the package[1]. That's setuptools. The line between the two is pretty clear; this is similar to the split between dpkg/apt or rpm/yum, except setuptools itself has some built-in dependency resolution support. [1] Assuming it's not a wheel. > I am, yes. And as ridiculous as that may sound it's utterly crucial. And a security nightmare. > Want to know what's really shit about python? Do you know what's shit about dealing with just about every language out there? Pick a language with its own package management, and the moment it steps outside of its own runtime environment, this problem crops up. Want to know why I think there's little chance of this working? It's nothing to do with Python and everything to do this being a nightmare for sysadmins.

crdoconnor 10y ago
>Have you proposed this to anyone in the PSF? I'm not interested in getting involved in their politics. >And a security nightmare. Absurd. >Do you know what's shit about dealing with just about every language out there? Not this. You might have noticed a variety of java programmers saying "nope, not an issue here". >Pick a language with its own package management, and the moment it steps outside of its own runtime environment The issue is not at all to do with stepping outside of the runtime environment and everything to do with running code in an uncontrolled environment. The solution is to control the environment as much as you can and fail cleanly if you can't. >Want to know why I think there's little chance of this working? No, I have no interest in what you think any more.
- talideon 10y ago
  > I'm not interested in getting involved in their politics. Then why did you even bring them up? > Absurd. Not if you're a sysadmin. > Not this. You might have noticed a variety of java programmers saying "nope, not an issue here". Because JNI is barely used. This isn't the case with Python, or Ruby, or a host of other lanuages. > No, I have no interest in what you think any more. Don't be an ass.