5 ms·

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 1

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
    And that's where things go off the rails. A release that is only supported for five years is a hobby project. The kind of software projects that make the world go round continue past the lives of their original authors and can easily span decades. 5 years is just enough for the original shake-out.
    - pas 6y ago
      Yes, ok, thanks, the Python foundation will immediately spend a lot of time and money to support releases for 2 decades. How could they not know!? /s That out of the way, you're right that some niches require a lot longer cycles, but it's the big big biiiig advantage of FOSS. Downstream can maintain it for as long as they wish. As you said things got shaken out by the community for free basically, and if some serious software is so so serious that upgrading and retesting/certifying is somehow more expensive than trying to airgap an EOLed pile of libs (while at the same time it needs support) then the stakeholders can do it.
      - xorcist 6y ago
        No sarcasm needed, Red Hat happily invests time and money in supporting it until 2024. That might have been an easy eay to provide upstream releases too, had the Python maintainers not been intent on using deprecations as an instrument to get the community moving. That strategy doesn't work very well however, as we've seen when TLS 1.2 was held off from Python 2.
    - di4na 6y ago
      I mean i am sure we would do that if any of the user company would want to pay the price for that. None of them want. You probably multiply the price by at least 10 (i would say add at least +1.5 to the multiplier for every year of support and that is probably highly conservative). Come back when they are ready to pay for that.
    - gchamonlive 6y ago
      > A release that is only supported for five years is a hobby project. I believe what you are trying to say is that you chose the wrong tool for the job. It is really condescending to lash out on other projects like that just because they don't share the same needs as you. They owe you nothing. Python is free and open source, just fork the damn language spec and support it yourself.
- deleted 6y ago
  [deleted]
deleted 6y ago
[deleted]
at_a_remove 6y ago
Yes, the technical reason was outlined above. Our Big Software Vendor in the field depends on specifically the products of 10.2.1. They're extraordinarily clear on that. So I assume that the geodatabases, the address locators, and such are all the sticking points in terms of the "products" of ArcMap. I suspect that sometimes their software dips into that specific version of arcpy, as well. Until the vendor hops, we cannot hop. It's a problem that will be eventually fixed, but I bring it up because many people here at HN think of greenfield development often, and also in industries where tons of iteration are met with approval.
- chaz6 6y ago
  That sounds very familiar. My company deployed a patch so that their webmaps continues working after flash became end of life. We still use 10.2.1 for most things. Thankfully I have ArcGIS Pro on my laptop. I had to move heaven and earth to get it.

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
  And that's where things go off the rails. A release that is only supported for five years is a hobby project. The kind of software projects that make the world go round continue past the lives of their original authors and can easily span decades. 5 years is just enough for the original shake-out.
  - pas 6y ago
    Yes, ok, thanks, the Python foundation will immediately spend a lot of time and money to support releases for 2 decades. How could they not know!? /s That out of the way, you're right that some niches require a lot longer cycles, but it's the big big biiiig advantage of FOSS. Downstream can maintain it for as long as they wish. As you said things got shaken out by the community for free basically, and if some serious software is so so serious that upgrading and retesting/certifying is somehow more expensive than trying to airgap an EOLed pile of libs (while at the same time it needs support) then the stakeholders can do it.
    - xorcist 6y ago
      No sarcasm needed, Red Hat happily invests time and money in supporting it until 2024. That might have been an easy eay to provide upstream releases too, had the Python maintainers not been intent on using deprecations as an instrument to get the community moving. That strategy doesn't work very well however, as we've seen when TLS 1.2 was held off from Python 2.
  - di4na 6y ago
    I mean i am sure we would do that if any of the user company would want to pay the price for that. None of them want. You probably multiply the price by at least 10 (i would say add at least +1.5 to the multiplier for every year of support and that is probably highly conservative). Come back when they are ready to pay for that.
  - gchamonlive 6y ago
    > A release that is only supported for five years is a hobby project. I believe what you are trying to say is that you chose the wrong tool for the job. It is really condescending to lash out on other projects like that just because they don't share the same needs as you. They owe you nothing. Python is free and open source, just fork the damn language spec and support it yourself.
deleted 6y ago
[deleted]

deleted 6y ago

[deleted]

at_a_remove 6y ago

Yes, the technical reason was outlined above. Our Big Software Vendor in the field depends on specifically the products of 10.2.1. They're extraordinarily clear on that. So I assume that the geodatabases, the address locators, and such are all the sticking points in terms of the "products" of ArcMap. I suspect that sometimes their software dips into that specific version of arcpy, as well. Until the vendor hops, we cannot hop. It's a problem that will be eventually fixed, but I bring it up because many people here at HN think of greenfield development often, and also in industries where tons of iteration are met with approval.

chaz6 6y ago
That sounds very familiar. My company deployed a patch so that their webmaps continues working after flash became end of life. We still use 10.2.1 for most things. Thankfully I have ArcGIS Pro on my laptop. I had to move heaven and earth to get it.