4 ms·

> However, I'm loath to continue working on it because there are few tasks more tedious, filled with annoying edge cases and thankless than this. That, in a nu

> However, I'm loath to continue working on it because there are few tasks more tedious, filled with annoying edge cases and thankless than this. That, in a nutshell, is the problem. > Plus I know it would never make it into pip because "it's not pip's job". There are good reasons it wouldn't make it into pip: something like that is more the realm of setuptools, rather than pip. > The only one I can think of is to packages like libpq-dev and libjpeg-dev and even the C compiler installable via pip and get the maintainers of pillow/psycopg2/whatever else to remove all their horrible hacky code to look for these dependencies on the system itself. The 'horrible hacky code' is autotools 90% of the time, and while I'd like to see if die in a fire and for pkgconf to replace it as far as library detection goes, it's not going away any time soon. Also, there is next to no chance of what you propose happening: you're essentially proposing a parallel system package management system, 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.

deleted 10y ago
[deleted]
crdoconnor 10y ago
>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.

deleted 10y ago

[deleted]

crdoconnor 10y ago

>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.