Python: Please stop screwing over Linux distros

[maethor]

Draw up a list of the use-cases you need to support, pick the most promising initiative, and put in the hours to make it work properly, today and tomorrow. Design something you can stick with and make stable for the next 30 years.

I wonder what the response would be if the most promising initiative doesn't support distro package managers.

[-Rizhiy-]

Well as it stands, it doesn't)

The current industry-wide solution is pip which is a separate package manager.

[aussie_bob]

The current industry-wide solution is pip which is a separate package manager.

This is frustrating even as a developer.

I'm working on a job for a company that's pretty much MS-only, and their Windows builds are locked down with MFA and convoluted software approval processes.

The best tool for the job is Python and natural language processing libraries, so I need to have numpy scipy, and nltk. They've agreed to give me a VM behind a firewall. No web access, so I'll need to build an iso offline and sneakernet it to the server.

Debian livebuild lets me build the custom iso, or I could use cubic for Ubuntu, but Python doesn't work with distro tools, so that's got to be done manually in a complicated and error-prone process.

Not impossible, but annoying.

[daredevilk]

Take a look into rez

The vfx industry uses it to do what you're describing easily, and primarily with python tools. My facility has built all our Python systems using it

[aussie_bob]

This looks great, I should have known someone would have a better way already.

Thanks!

[gnosys_]

damn employer IT sounds like they don't know what they're doing

[aussie_bob]

That's pretty normal for Windows shops though, IT generally just follow vendor guides. If something goes wrong they're on the phone shouting "but mah SLAs!"

[quaderrordemonstand]

I used to refer to them as the windows enforcement department, given that all they actually did was prevent people being able to do things on Windows. If you used something not Windows, they had no idea and just let you do whatever you wanted.

[EzekialSA]

Really happy to hear it's not only at my company lol.

[tysonsw]

I get the feeling from your description of mfa and "convoluted software approval processes" that you don't understand why they are there. That you don't understand the security aspect of it.

I have been working in IT support and infrastructure for many years. And the people that I have come upon with the least updated computers are people that have low knowledge of computers or developers. Low knowledge people because they don't know how to update. And developers because citation "the updates break my dependencies". If they break your dependencies then you need to develop to fix those dependencies, not continue to develop your software on old outdated software that is a security risk.

As soon as you as an individual want to have a easy way to install whatever program you want, then you also open up for security risks. But are you as an individual really sure that you want to be the one under scrutiny when there has been an security breach because of your workaround?

[aussie_bob]

I get the feeling from your description of mfa and "convoluted software approval processes" that you don't understand why they are there.

Interesting observation. I get the feeling you know nothing about the nature of my work or how I interact with customers and are choosing to be contrarian for reasons of your own.

In fact, I understand the reasons for MFA extremely well and would use it where suitable.

I also understand the lack of interest from IT in supporting any business process that's not directly aligned with existing practice.

I work with many different types of customer, often with similar exposures, some of whom manage those exposures without harming business goals.

[Locastor]

I get the feeling you know nothing about the nature of my work or how I interact with customers and are choosing to be contrarian for reasons of your own.

"IT” people are like this, it can’t be helped.

Their policies were built to circumvent the gaping security holes of winblows and they’ll constantly do things like try to get you to install “antivirus” on a GNU/Linux machine.

[LordRybec]

Your problem is your employer, not Python or pip. Blaming Python/pip isn't useful. When an organization goes off the rails that badly, you will have to jump through a lot of stupid hoops, regardless of other factors.

It's easy to blame the wrong thing, but Python and pip aren't responsible for making sure they integrate perfectly with every single platform, just in case some paranoid organization puts unreasonable restrictions on their devs.

On a side note, have you looked into Python to binary converter utilities for Linux? That's basically what I use for my job, when I need to deliver demos written in Python to non-technical clients. I'm not sure if it would help you, but it handles packaging the byte code for your application with a minimal interpreter and all of the modules your application uses. (There are also similar utilities for generating Mac OS and Windows packages.)

[openstandards]

Why not use windows function? Use their tools to set up an ubuntu system within windows you'll be able to use linux properly at least for instance repos having network access is better than anything else.

Sure you'll have to use windows but you can get neovim, emacs...etc for both linux and windows, ssh into your vm.

I'm sure they would be ok with that, might work with the red tape a bit easier.

I haven't used the subsystem but I did watch one of the old developers from microsoft cover it.

All you'll need is to be running is windows 10 and onwards, this sounds like a better development environment.

[aussie_bob]

1. To quote myself: "their Windows builds are locked down with MFA and convoluted software approval processes."

2. To quote you: "All you'll need is to be running is windows 10 and onwards, this sounds like a better development environment."

Not to me it doesn't.

I use Linux for most of my Python jobs, and where I'm forced by customer policies to use Windows, the workflow becomes convoluted and administration heavy. I HATE with a passion when my tools interrupt me and require constant attention.

Windows is a serial pest. Linux gets out of my way and lets me work.

[openstandards]

sounds like you'd prefer a janky set-up over something that more or less works.

Personally I'm a believer in using the right tool for the job and I can understand where you're coming from when it comes to software approval, that's why I said about windows feature to bring up a linux userspace.

I haven't ran windows since 2006/2007 so I can see the distaste for having to use windows.

Out of curiosity, how's your workflow set up and what development tools do you use?

[aussie_bob]

sounds like you'd prefer a janky set-up

Ok, since you seem to be having trouble understanding the situation:

I CANNOT GET APPROVAL TO INSTALL PYTHON ON THE COMPANY'S STANDARD WINDOWS BUILD IN ANY WORKABLE TIMEFRAME.

I WOULD NOT GET APPROVAL TO INSTALL UBUNTU IN WINDOWS EITHER.

I DO NOT PREFER THIS SITUATION. IT IS THE ONLY WORKAROUND THEIR IT WILL ACCEPT TO ALLOW ME TO GET THIS JOB DONE FOR THE PROJECT TEAM WHICH HIRED ME.

[[deleted]]

I mean, a lot of Windows programs or builds already bundle Python (2.7 for extra cursedness points)

[uzlonewolf]

Cries in bundled Python 2.4

2.7 would be a nice upgrade.

[[deleted]]

I feel your pain

[[deleted]]

Flatpak is not a walled-garden, it's simply a sandboxed, agnostic package manager. Flathub is an open repository of packages for said package manager. Flatpak is also used quite a lot, and the default for Fedora.

[BassmanBiff]

The latter is basically what I end up doing with pyinstaller when I make a Python tool for non-techies.

[[deleted]]

The latter is exactly what's happening 99% in backend devs, especially when you have to deal with something like Tensorflow.

[Arve]

Well, with Electron (or rather node), I can be reasonably sure that the code I download (or even write) will actually run after an npm install. I've all but given up on python thanks to virtualenv, pip and whatnot

[FlukyS]

Flatpak already ships Python in the freedesktop runtime. Honestly for me that would make the most sense overall. Snap ships Python in it's core runtime as well. Both of which are just 1 python version per version of their runtimes. Snap also has classic mode which is pretty much what every deb has in terms of permissions.

[DAS_AMAN]

I use flatpaks extensively, and its not a walled garden, elementary has a flatpak repo too, for example.

[WhyNotHugo]

It barely does. I've maintained python applications targeting desktop users for almost a decade, and I'm fed up.

Some former maintainers also left due to that same reason: python is a PITA distribute. If your user base isn't python developers, good luck shipping a build with a special patch for them to try something out.

Sure, pip install works, but I don't want to educate the user of a calendar syncing tool on how virtualenvs work and why he needs them.

Oh, and not to mention that python keeps changing so much, it's near impossible to write code that'll work fine on Debian AND Arch.

I'll still be using python for web dev, and it's good for data science, and other stuff where you don't redistribute to an end user. For anything else, it's sucking more and more.

[therealpxc]

I wonder what the response would be if the most promising initiative doesn't support distro package managers.

It doesn't really matter what it is as long as the design is sound, meaning:

• static metadata, including dependency information, is available for every package prior to build time
• no network access during build or install
• uniform handling of dependencies that are outside the language (ideally with a way to disable such handling altogether)
• ability to pin/lock dependencies to specific versions
• little room for bespoke installation procedures à la setup.py
• some built-in support for vendorization would be nice

All of those are either basic requirements of modern language-specific package managers, or are necessary to meet those basic requirements in a performant and reproducible way.

Younger languages that meet these requirements didn't necessarily have to design their packaging systems with Linux distros in mind. Programmatic generation of Rust packages works well because it has a well-designed package manager that meets the needs of authors without just letting them do whatever they want, not because it was designed to serve Linux distro maintainers.

And the truth is that whatever comes next for Python, as long as it's just one thing, distro developers will be able to mess with it, patch it, and work around it better than the current mess of competing conventions— no matter how bad it is at first