5 ms·

I'm in an awkward chain of dependencies. You see, in my industry there are very few players, and the current version of their software depends on much function

I'm in an awkward chain of dependencies. You see, in my industry there are very few players, and the current version of their software depends on much functionality and rather exacting specifications from products which are made using ArcGIS 10.2.1. Not 10.2. Not 10.2.2. This is a very conservative hunk of software because this is not a "move fast and break things" industry. This is a "people die when we screw up" industry. So they haven't moved from ArcGIS 10.2.1 for our version. Change is coming but they have to be careful. So ArcGIS 10.2.1 comes with a python install of 2.7.2 (I am pretty sure it is .2). And you are very strongly advised NOT TO UPGRADE THAT in big bold letters on the relevant help pages. So I need to use 2.7.2 to manipulate some stuff out of ArcGIS 10.2.1 to do "stuff." And there I sit.

mumblemumble 6y ago
Well, the good news is, Python 2.7.2 still works, as does pip 20. If you haven't already, I'd recommend setting up a PyPI proxy and backing it up. I don't know what PyPI's policy is around supporting old packages or versions of the package manager are, but I have learned the hard way from working on other legacy software stacks that things have a way of disappearing from the Internet when you're not looking.
- at_a_remove 6y ago
  Well, Python 2.7.2 works, but I have never been able to get pip to work at all in my install. Instead I get a circular chain of dependencies ... So if it isn't in the standard library, I haven't been using it. Pity, because lxml seems like it would solve some of my issues.
  - stqism 6y ago
    At my current company we’re in an awkward situation with python 2.7.1 and 2.7.5, I’ve found that a easy solution to circular dependencies caused by the new resolver is installing pip==20.2.4 and an older setuptools (I don’t have this version memorized) before doing anything.
wolf550e 6y ago
That's a version of python that does not send SNI when opening TLS connections, so sites that don't have a dedicated IP address for the domain cannot support TLS with such clients, and most sites that do have a dedicated IP address won't support TLS "just because" (no SNI - get self signed dummy cert or closed connection). So the first thing I would have to do with such Python is monkeypatch ssl.
- at_a_remove 6y ago
  I had sort-of traced down the problem to something involving SSL, but I am glad to see that someone else has confirmed it. Thank you. Sadly, I have no idea how to monkeypatch SSL.
cool-RR 6y ago
"And there I sit." There you chose to sit.
mrweasel 6y ago
But that’s beyond conservative, Python3 isn’t new, it’s more than a decade old at this point. I can understand that in some industries you don’t easily upgrade, because of testing and certifications. It’s however also possible to put of upgrades for so long that it becomes reckless. If you’re stuck on Python 2.7 in 2021, and your code could kill people, you’re putting people in danger by being reckless. I’ve also seen people claiming a need for stable platform as a reason to not upgrade. Well, running Windows Server 2008 in 2021 you indeed have a “stable” platform, but it should come as no surprise when modern protocols and encryption isn’t working.
- pjmlp 6y ago
  Yesterday in the Java thread I mentioned having done some Java 1.4 stuff in 2016. The customer was running Red-Hat Enterprise 5.0, and it was going to stay that way as long as Red-Hat would be willing to support it.
  - sofixa 6y ago
    > The customer was running Red-Hat Enterprise 5.0, and it was going to stay that way as long as Red-Hat would be willing to support it. Making the migration when RH stop supporting it extremely complex and expensive, instead of iterating.
- at_a_remove 6y ago
  Oddly, not killing people is the reason for the very slow iterations.
- jacquesm 6y ago
  > If you’re stuck on Python 2.7 in 2021, and your code could kill people, you’re putting people in danger by being reckless. It's comments like this that make me very sad for the software industry as a whole. No, he's not being reckless and he's not putting people in danger. The people who make breaking changes to languages, APIs, operating systems and libraries are the ones that put people in danger and that cause others to stop upgrading because they quite reasonably fear breaking changes that could have far reaching consequences. The price of backwards incompatibility is poorly understood.
ashurov 6y ago
Same problem here..
nwallin 6y ago
I work for Esri, but I specifically work on ArcGIS Pro which has shipped with python 3.x for quite a while. (since before I joined the company anyway) ArcGIS 10.2.1 comes with 2.7.5, [1] and is very, very old. It was released in Jan 2014 and hit EOL in 2019. [2] All not-EOL versions of ArcGIS Server support python 3.x. But if you're using ArcMap, upgrading to a later version will not move you to python 3.x: you'll have to migrate to ArcGIS Pro for that. (note for the unaware: this is not a "well just buy the more expensive thing" post. ArcMap and ArcGIS Pro share the same license.) I recommend migrating to Pro for this and other reasons, but I understand that a lot of orgs don't have that on their roadmap. Out of curiosity, is there a technical reason why your org isn't using a supported version, or is it an "ain't broke" situation? I'd ask migrating to ArcMap to Pro, but if you're on 10.2.1... yeah. [1] https://support.esri.com/en/technical-article/000013224 https://support.esri.com/en/technical-article/000013224 [2] https://support.esri.com/en/Products/Desktop/arcgis-desktop/arcmap/10-2-1 https://support.esri.com/en/Products/Desktop/arcgis-desktop/...
- a1studmuffin 6y ago
  Hang on a second, you consider Jan 2014 to be "very, very old"? Commercial software often has dependencies on libraries going back decades.
  - diarrhea 6y ago
    A finished software product that gets regular updates is old by the time it turns 7, I'd agree on that. Dependencies on libraries is a different story, there's only so many ways you can implement a functionality, and some of these happen to be decades old!
  - Youden 6y ago
    It can be "very, very old" in its context. If a new release comes out every year, support duration is 5 years and you're 2 years past EOL, I'd agree that the software can be called "very, very old".
    - jacquesm 6y ago

mumblemumble 6y ago

Well, the good news is, Python 2.7.2 still works, as does pip 20. If you haven't already, I'd recommend setting up a PyPI proxy and backing it up. I don't know what PyPI's policy is around supporting old packages or versions of the package manager are, but I have learned the hard way from working on other legacy software stacks that things have a way of disappearing from the Internet when you're not looking.

at_a_remove 6y ago
Well, Python 2.7.2 works, but I have never been able to get pip to work at all in my install. Instead I get a circular chain of dependencies ... So if it isn't in the standard library, I haven't been using it. Pity, because lxml seems like it would solve some of my issues.
- stqism 6y ago
  At my current company we’re in an awkward situation with python 2.7.1 and 2.7.5, I’ve found that a easy solution to circular dependencies caused by the new resolver is installing pip==20.2.4 and an older setuptools (I don’t have this version memorized) before doing anything.

wolf550e 6y ago

That's a version of python that does not send SNI when opening TLS connections, so sites that don't have a dedicated IP address for the domain cannot support TLS with such clients, and most sites that do have a dedicated IP address won't support TLS "just because" (no SNI - get self signed dummy cert or closed connection). So the first thing I would have to do with such Python is monkeypatch ssl.

at_a_remove 6y ago
I had sort-of traced down the problem to something involving SSL, but I am glad to see that someone else has confirmed it. Thank you. Sadly, I have no idea how to monkeypatch SSL.

cool-RR 6y ago

"And there I sit." There you chose to sit.

mrweasel 6y ago

But that’s beyond conservative, Python3 isn’t new, it’s more than a decade old at this point. I can understand that in some industries you don’t easily upgrade, because of testing and certifications. It’s however also possible to put of upgrades for so long that it becomes reckless. If you’re stuck on Python 2.7 in 2021, and your code could kill people, you’re putting people in danger by being reckless. I’ve also seen people claiming a need for stable platform as a reason to not upgrade. Well, running Windows Server 2008 in 2021 you indeed have a “stable” platform, but it should come as no surprise when modern protocols and encryption isn’t working.

pjmlp 6y ago
Yesterday in the Java thread I mentioned having done some Java 1.4 stuff in 2016. The customer was running Red-Hat Enterprise 5.0, and it was going to stay that way as long as Red-Hat would be willing to support it.
- sofixa 6y ago
  > The customer was running Red-Hat Enterprise 5.0, and it was going to stay that way as long as Red-Hat would be willing to support it. Making the migration when RH stop supporting it extremely complex and expensive, instead of iterating.
at_a_remove 6y ago
Oddly, not killing people is the reason for the very slow iterations.
jacquesm 6y ago
> If you’re stuck on Python 2.7 in 2021, and your code could kill people, you’re putting people in danger by being reckless. It's comments like this that make me very sad for the software industry as a whole. No, he's not being reckless and he's not putting people in danger. The people who make breaking changes to languages, APIs, operating systems and libraries are the ones that put people in danger and that cause others to stop upgrading because they quite reasonably fear breaking changes that could have far reaching consequences. The price of backwards incompatibility is poorly understood.

ashurov 6y ago

Same problem here..

nwallin 6y ago

I work for Esri, but I specifically work on ArcGIS Pro which has shipped with python 3.x for quite a while. (since before I joined the company anyway) ArcGIS 10.2.1 comes with 2.7.5, [1] and is very, very old. It was released in Jan 2014 and hit EOL in 2019. [2] All not-EOL versions of ArcGIS Server support python 3.x. But if you're using ArcMap, upgrading to a later version will not move you to python 3.x: you'll have to migrate to ArcGIS Pro for that. (note for the unaware: this is not a "well just buy the more expensive thing" post. ArcMap and ArcGIS Pro share the same license.) I recommend migrating to Pro for this and other reasons, but I understand that a lot of orgs don't have that on their roadmap. Out of curiosity, is there a technical reason why your org isn't using a supported version, or is it an "ain't broke" situation? I'd ask migrating to ArcMap to Pro, but if you're on 10.2.1... yeah. [1] https://support.esri.com/en/technical-article/000013224 https://support.esri.com/en/technical-article/000013224 [2] https://support.esri.com/en/Products/Desktop/arcgis-desktop/arcmap/10-2-1 https://support.esri.com/en/Products/Desktop/arcgis-desktop/...

a1studmuffin 6y ago
Hang on a second, you consider Jan 2014 to be "very, very old"? Commercial software often has dependencies on libraries going back decades.
- diarrhea 6y ago
  A finished software product that gets regular updates is old by the time it turns 7, I'd agree on that. Dependencies on libraries is a different story, there's only so many ways you can implement a functionality, and some of these happen to be decades old!
- Youden 6y ago
  It can be "very, very old" in its context. If a new release comes out every year, support duration is 5 years and you're 2 years past EOL, I'd agree that the software can be called "very, very old".
  - jacquesm 6y ago