So that's why python screwed Windows 7

[PlainName]

Just having a public profile will get you that kind of hassle

[Karel]

They get very nasty and are filled with layers of disgusting entitlement.

Please try to ignore them. Many KiCad users appreciate what the devs are doing and understand that they
have limited resources.

[SiliconWizard]

I agree with dunkemhigh though about the fact there's a line between not being able to support a given platform for lack of resources (yes, additional platforms are additional work, if just for building and testing, and yes, KiCad's dev. means compared to the output are very limited IMO) and *deliberately* (which unfortunately was the idea conveyed by delfinom here, so we're not even making that up, that's clearly expressed, they even go as far as kind of "insulting" Win 7 users - not very cordial if you ask me.)

Now this is again only due to Python here, not directly KiCad, and the only issue is that devs decided (probably a long time ago already) to use Python as a scripting language. Now it's too late and there's nothing much they can do about it. They could disitribute KiCad with an older version of Python though - IIRC, 3.9 is the latest version that's supported on Win 7 - which would work just fine for KiCad's needs. But that would be limiting the future of KiCad and I understand not doing that.

One questionable point is that KiCad (at least the layout editor) just doesn't even work with basic functionalities without Python. I would personally not have based almost "core" functionalities on Python. I don't like this kind of dependency. I would have at most included it as a means for users to write plug-ins, but not for "internal" uses. Just my opinion.

As to KiCad on Win 7 - as I talked about quite a while ago now (a few months I think?), I *have* managed to build it for Win 7 and routinely use it on Win 7 as of late. I've used it enough now to know that it works fine and have not encountered any issue that was specific to this build. I have decided, so far, not to share it for a few reasons. One of them is that I was afraid of getting hostility from the KiCad team. And this thread kind of reinforces this concern. Those of you who'd be interested in discussing that, they can PM me.

And that said, this is not *against* KiCad devs in general, at all. KiCad is great and they are doing an awesome job, especially given the limited means they have. As to the above remark - uh no, Eagle is not better. It's atrocious compared to KiCad 6.

[PlainName]

I don't get paid on my off-hours to be cordial

Hope that was a joke but, in case it wasn't, perhaps you should treat off-hours as being actually off duty, if being cordial is too hard to do without being paid.

[nctnico]

@delfinom: May I add that Kicad's mission statement still says 'The goal of the KiCad project is to provide the best possible cross platform electronics design application for professional electronics designers'. Maybe change  'professional electronics designers' into 'hobbyists' to make sure professional CAD users don't ask for features and/or don't publicly rant at people that offer constructive critisism who might even be interested in a paid -for commercial use- Kicad version. Your rant certainly is not helping your case in any way.

However, my underlying point is not so much supporting Windows 7, but what is the next problem that occurs from switching to 'the latest and gratest'? Was the move to a newer Python (that no longer works on Windows 7) driven by new functionality in Python Kicad could absolutely not do without or just by wanting to use 'the latest and gratest'? In the past I have worked with several programmers that always wanted to use the latest version of whatever without really thinking about what the new version broke in it's wake or what the consequences where for the people using / maintaining systems to run their software. Developing software that is easy to deploy and keep running long term from a system administrator's perspective is also part of software engineering.

[SiliconWizard]

Was the move to a newer Python (that no longer works on Windows 7) driven by new functionality in Python Kicad could absolutely not do without or just by wanting to use 'the latest and gratest'?

As I said (from hands-on experience here), earlier versions of Python 3 work just fine. Actually, a number of Python scripts that are part of the latest source code version are rather old now and they have probably been written for old versions of Python 3.x without having been updated. So no problem with that. But again, I totally understand why they would update Python to a recent (if not last) version. Newer versions contain bug/security fixes. That's understandable.

You may rather either ask Python maintainers why they stopped supporting Windows 7, or - as I hinted - why KiCad maintainers chose to use Python, at your convenience - but again, now it's too late. They have to deal with it.

The latest Python (3.10) I'm using for my Win 7 build is from MSYS2. It works a treat on Win 7. But that's because MSYS2 provides packages for that (and they had to patch Python).
So one reason KiCad maintainers cannot provide Win 7-compatible binaries is that they stopped (officially) supporting builds on MSYS2 on Windows. Which is questionable, but their choice. That's what I use. Now unfortunately, MSYS2 maintainers announced earlier this year that they will stop supporting Win 7 too - they said by the end of this year. We'll see. At the moment, I can still build KiCad 6 with the latest versions of everything (Python, wxWidgets...) This will still be doable even after MSYS2 stops supporting Win 7 as long as KiCad doesn't absolutely *require* newer versions of libraries that may not be available then. But for now, I have built version 6.0.8 to day successfully and will switch to it after some testing.

As to purely the security argument ("we don't support Win 7 anymore because it's now unsecure, blah...") - didn't say that's what KiCad maintainers said, but that's an argument that's very often used by software maintainers - the sheer example of Firefox that still supports it, while web browsers are typically the kind of software for which security is the most problematic - should tell them one thing or two. Just saying.

[PlainName]

I note that Microsoft is pushing W11 now, and it's conceivable that W10 will go the way of W7. If that happens, will Python and Kicad turn off the ability to run on W10?

The comments to an article on The Register are interesting: hardly anyone wants to go to W11. It is very reminiscent of when W10 came out and people didn't want to move from W7, and since this time it requires a hardware upgrade (unless you hack it) the determination to stick may be a bit more robust, leaving more users 'out of support'. Will they still be ignored by Python/Kicad?

[edit: typos]

[Karel]

I don't care as long as they support Linux 

 

[PlainName]

Does it work on out-of-support Linux distros?

[nctnico]

Does it work on out-of-support Linux distros?

Given my experience with the 'portability' of Python my guess is not. Python in itself is such a moving target that using the latest version of any module likely means needing a Linux version that is very recent. When using Debian, which always lags behind due to rigorous testing, you might be out of luck even with the most recent version.

[PlainName]

Python is starting to sound like something to avoid if one isn't a an upgrade freak.

[Karel]

Up until a couple of weeks ago, I was still using Opensuse Leap 15.3 and KiCad was stuck at V5.
So, I moved on to Leap 15.4 and after that I was able to install KiCad V6.
But I had to do it anyway because Leap 15.3 will be soon without support (like your windows 7).

https://en.wikipedia.org/wiki/OpenSUSE#Version_timeline

Ofcourse there's always a period of overlap so that users can migrate without too much stress.

[PlainName]

It's a bit like Oracle, isn't it? They're telling you what you can run it on, not vice versa. Imagine if every vendor did that and you wound up with A needing one version and B refusing to run on that version. You'd end up with an entire machine just to run one particular application.

[JohnG]

You'd end up with an entire machine just to run one particular application.

Hmm, I've seen more than a few of those in my career, sometimes running Windows.

John

[PlainName]

Sure, but then you are really buying the application and it just happens to come on that machine. Kicad, and definitely Python, aren't in that class. Or shouldn't be!

[Karel]

It's a scandal!

[free_electron]

Python is starting to sound like something to avoid if one isn't a an upgrade freak.

remember the 2.7 to 3 problem ? that proved all...

[SiliconWizard]

Other than compatibility with some OSs (at least with official builds, because as I said, MSYS2 provides Python 3.10.7 for Win 7), another more general issue with embedding Python in some application, like KiCad does, are the installed modules.

If for your Python scripts within KiCad, you want to import some module that is not part of the embedded Python distribution, here begin the problems. Installing a particular module for a standalone Python usually involves using pip (as long as pip is installed on your system... and you manage to deal with paths so that you install modules for the right version of Python if you have several installed, which is pretty common). Installing a module in KiCad's embedded Python if it's not already in it is uh. Non-trivial to put it lightly.

Fun stuff.

[ataradov]

Installing a particular module for a standalone Python usually involves using pip

But if you are not using Python for scripting, then there is nothing to install anyway, so you might as well treat the supplied modules as all that is available.

I'm not a fan of Python for scripting, but pretty much all scripting languages suck one way of the other.

[Karel]

Eagle had a good scripting language and because it was C-style syntax it was also easy to learn.
Documentation was also good.

[ataradov]

Sure, creating your own domain specific language is a good option. But it is also a whole project of its own, and if resources are limited, it may not be a viable option.

[PlainName]

You only have to do it once (with a bit of maintenance). Or you could fork a language to keep control over it.

Slickedit, 'only' an editor, has scripting. Indeed, much of its functionality is through its scripting, so it's reasonably easy for the user to modify its behaviour or implement some missing feature (if they can think of one!). AFAIK, most scripts from a decade or more ago work fine - there will be some functions that have changed or become obsolete as the product evolves, of course. Runs on Linux 2.6+, Windows 7+, Mac something or other. Upgrades are complete non-thinkers - the possibility that something will break is very remote indeed. The worst experience I've had in upgrades is when it copies the previous version's config and forgets some setting.

This kind of thing can be done. The thought of Slickedit using jobbing Python horrifies me, to be honest.

[SiliconWizard]

Installing a particular module for a standalone Python usually involves using pip

But if you are not using Python for scripting, then there is nothing to install anyway, so you might as well treat the supplied modules as all that is available.

Not sure I quite got what you meant here. First, KiCad does require Python even if the user doesn't use it for custom scripting (but for this, you can indeed expect the embedded Python to have all requires modules). And otherwise, I guess you meant that the user should only use available modules, and nothing more? That sounds reasonable, but in practice, many Python users expect to have access to the whole Python ecosystem, and the whole benefit of Python is precisely the amount of existing third-party modules. It's problematic to offer Python, yet restrict the user to a set of modules that is not even documented. You can only try to import and see if it chokes or not. Pretty.

Another point is that Python uses kind of a mess of environment variables, so that some users could actually have KiCad's Python point to external Python's installs, which would further mess with compatibility. So in practice, for instance, some users may have access to Python modules on their particular machine that others do not, even with the exact same KiCad version. Yay.

I'm not a fan of Python for scripting, but pretty much all scripting languages suck one way of the other.

I won't deny that. Would have favored Lua though. Much cleaner, much easier to use, a lot fewer dependencies, very small footprint. Of course, it doesn't have the ecosystem that Python has, but see above for the ecosystem in question...

[ataradov]

Not sure I quite got what you meant here.

I mean if they used LUA or TCL or something more standard and stable, then there would not be pip for them. So, if you treat the embedded Python as a thing that also has no standard repositories, then it would be no different than LUA or TCL in that respect.

I think this is more or less standard for embedded Python. Blender is also using it to a huge degree and I think the situation is about the same - you just assume that all the modules that are provided is all you have.

[Karel]

Sunsetting support for Windows 7 / 8.1 in early 2023

https://support.google.com/chrome/thread/185534985/sunsetting-support-for-windows-7-8-1-in-early-2023