VS Code Python Environments Nisan Güncellemesi: Hız Farkı

Q: uv ile oluşturulmuş ortamları otomatik buluyor mu?

Büyük ölçüde evet. uv'nın oluşturduğu .venv klasörünü tanıyor, ama açıkçası tam entegrasyon henüz tam anlamıyla olgunlaşmadı. Bazı edge case'lerde manuel path gösterimi gerekebiliyor. Gelecek güncellemelerde daha iyi olmasını bekliyorum.

⏱️ 10 dk okuma📅 28 Nisan 2026👁️ görüntülenme

Geçen hafta bir müşteride Remote-SSH ile çalışırken, VS Code’un Python ortam keşfi tam 45 saniye sürdü. Adam bana döndü, “Aşkın bir düşüneyim… bey, bu IDE mi yoksa Windows Update mi?” dedi. Gülsem mi ağlasam mı bilemedim. Bir bakıma, tam da öyle.

Bak şimdi, asıl mesele şu: Python Environments eklentisinin Nisan 2026 güncellemesi geldi ve o sınır bozucu bekleme neredeyse yok öldü. Abartmıyorum; 45 saniyelik sürünme, (belki yanılıyorum ama) çoğu senaryoda göz açıp kapayıncaya kadar bitiyor (inanın bana). İşte burada iş değişiyor.

Peki ne var bu pakette? Önce keşif tarafı hızlanmış, sonra Remote-SSH akışında gereksiz oyalanmalar azaltılmış, bir de arka planda daha akıllı bir tarama mantığı eklenmiş. Hani bazen “bu kadar fark eder mi?” dersiniz ya, burada eder gibi dürüyor; hatta ilk denemede ben de şaşırdım açıkçası (ilk duyduğumda inanamadım)

Neyse, çok uzatmayayım. Güncellemenin detaylarına birlikte bakalım. Kağıt üstünde küçük görünen bu dokunuşlar, gerçek kullanımda baya iş görüyor.

Neden Bu Güncelleme Önemli?

VS Code’da Python geliştiren biriyseniz, işin ilk dakikası biraz uğraştırıyor. Eklentiyi açıyorsunuz, sonra bir bakmışsınız ortam araması başlamış; hangi sanal ortam var, interpreter nerede, conda mı venv mi derken zaman gidiyor. Büyük projelerde bu daha da can sıkıcı oluyor, hele bir de uzak sunucuya bağlıysanız (özellikle Azure üstünde Remote-SSH ile çalışan ekiplerde) iş iyice uzuyor. Ben Logosoft’ta bunu birkaç müşteride gördüm; PET (Python Environment Tools) bazen takılıyor, bazen liste bomboş geliyor, bazen de yanlış interpreter seçili kalıyor. Can sıkar.

İlginç olan şu ki, Bu güncelleme tam da oraya dokunuyor. Üç şey öne çıkıyor: başlangıç hızı, güvenilirlik ve terminal/paket tarafındaki ufak ama işe yarayan düzeltmeler. Ama asıl mesele şu bence — Microsoft artık “her şeyi herkese taratmayalım, çoğu kişi zaten venv ya da uv kullanıyor” demiş gibi dürüyor. Açık konuşayım, yerinde bir karar. Çünkü o eski kapsamlı tarama bazen iyi niyetliydi ama biraz ağır çalışıyordu, hatta bazı ortamlarda gereksiz yere işi yokuşa sürüyordu.

Başlangıç Hızı: Artık Kahve Molası Vermeye Gerek Yok

Tembel Manager Keşfi (Lazy Discovery)

Eskiden ne oluyordu, biliyor musunuz? VS Code açılır açılmaz pipenv, pyenv, poetry — ne varsa hepsini yokluyordu. Hani sanki “acaba bu projede hangi araç var?” diye her köşeye bakıyordu. Güzel niyet, ama dur bir saniye; çoğu kişi bunların hepsini zaten kullanmıyor. Ben mesela projelerin çoğunda düz venv ya da son zamanlarda uv kullanıyorum, Poetry’yi işe her 10 projeden birinde anca görüyorum.

Bakın, Şimdi işler değişmiş. Bu manager’lar sadece gerçekten lazım olduğunda keşfediliyor. Yanı projenizde Pipfile ya da poetry backend’li pyproject.toml yoksa, eklenti gidip onları aramaya bile kalkışmıyor. Neden önemli bu? Küçük gibi dürüyor, ama etkisi baya hissediliyor — özellikle remote workspace tarafında, orada insanın sabrı daha çabuk tükeniyor zaten.

Kısa bir not düşeyim buraya.

Daha Hızlı Ortam Çözümleme

Eklenti aktif olduktan sonra interpreter’ın hazır hâle gelmesi de kısalmış. Teknik kısmı çok kurcalamayacağım ama özet şu: “extension activated” noktasından “interpreter ready” noktasına giden yol daha kısa olmuş. 2024’ün sonlarında bunu bir telekom müşterisinde test etmiştim — ortamda 8-10 saniyelik bir gecikme vardı, can sıkıyordu açıkçası. Şimdi aynı yerde 2-3 saniye civarına düşmüş. Fena değil.

Evet.

Daraltılmış Workspace Taraması — İşin Gerçek Kahramanı

Bak şimdi, bence güncellemenin asıl olayı burada. Eski varsayılan arama deseni ./**/.venv idi; yanı tüm workspace ağacını derin derin tarıyordu. Büyük bir monorepo varsa ya da Remote-SSH üstünden çalışıyorsanız… şey, sistem biraz nefes nefese kalabiliyordu (şaşırtıcı ama gerçek). PET prosesi 30+ saniye takılı kalıyor, sonra timeout döngülerine giriyordu; insanın içi şişiyor resmen (en azından benim deneyimim böyle)

Yeni varsayılan işe .venv ve */.venv. Yanı kök dizinle bir seviye altını tarıyor, bu kadar. Standart proje yapısı için gayet yeterli (bizzat test ettim). Eğer sizde daha derin iç içe sanal ortamlar varsa, python-envs.workspaceSearchPaths ayarından ekstra yol tanımlayabiliyorsunuz; işte orada kontrol tamamen sizde oluyor.

// settings.json örneği — derin yapılar için özel arama yolları
{
"python-envs.workspaceSearchPaths": [
".venv",
"*/.venv",
"projects/*/.venv",
"services/**/.venv"
]
}

Bir arkadaşım büyük bir Python monorepo’sunda çalışıyor; 15’e yakın microservice alt klasörde dürüyor,. Yapı bildiğiniz dallanıp budaklanmış durumda. Eski ayarla VS Code’u (belki yanılıyorum ama) her açtığında 40 saniye bekliyormuş. Bu ayarı düzenledikten sonra süre 3-4 saniyeye inmiş. Bana mesaj attığında “ya bu kadar basit miymiş” demişti. Açık konuşayım, bazen çözüm gerçekten bu kadar sade oluyor.

Tam da öyle.

Güvenilirlik: PET Çökünce Dünya Kararmıyor Artık

PET Crash Recovery

Daha önce PET prosesi çökerse, ki bu özellikle remote ortamlarda daha sık başımıza geliyordu, eklenti yarım yamalak bir hâlde kalıyordu. Ortam listesi bomboş görünüyordu, hiçbir şey seçilemiyordu, hatta restart atsak bile bazen toparlamıyordu; işte insanı en çok geren buglardan biri buydu.

Artık iş değişti. Çökme sonrası otomatik retry devreye giriyor, boş ya da bozuk yanıtlar da savunmacı biçimde ele alınıyor, yanı geçici bir PET hatası sizi sahipsiz bir ortam listesiyle bırakmıyor. 2025 başında bir finans kuruluşunda bunu birebir yaşamıştık — CI/CD pipeline’ını VS Code üzerinden test eden geliştiriciler sürekli “ortam bulunamadı” hatası alıyordu, biz de manuel olarak extension’ı disable edip tekrar enable ediyorduk; komik gibi dürüyor. Açıkçası baya yorucuydu.

Tuhaf ama, Evet.

Conda Base Ortam Düzeltmesi

Küçük bir detay: Bu taraf da ayrı sınır bozucuydu. Pencereyi yeniden yüklediğinizde conda base ortamı sanki başka bir named environment’mış gibi geri gelebiliyordu; sız base’i seçtiğinizi sanıyorsunuz,. Aslında arkada bambaşka bir ortam aktif oluyor. Sessiz sedasız değişiyor işte, insan sonradan fark ediyor; veri bilimi ekipleriyle çalışanlar bu sahneyi iyi bilir, “abi bu kütüphane neden yok?” sorusu genelde buradan çıkıyor.

Düzeltildi. Artık pencere yeniden yüklendikten sonra seçtiğiniz ortam doğru şekilde restore ediliyor, yanı base neyse base olarak kalıyor; küçük detay gibi görünüyor. Pratikte baya fark ettiriyor.

Terminal ve Paket Yönetimi: Küçük Ama Hayat Kurtaran Değişiklikler

Ha bu arada, paket listesi artık kendi kendine yenileniyor. Eskiden pip install requests çalıştırdıktan sonra listeyi elle tazelemek gerekiyordu; şimdi eklenti, site-packages içindeki metadata değişimini izliyor ve ekranı kendisi güncelliyor. Küçük gibi dürüyor ama günde 50 kere pip install yapan biriyseniz, açık konuşayım, baya rahatlatıyor (evet, doğru duydunuz)

Bir de şu var. Çoklu proje workspace’lerinde yeni terminal açınca artık hangi projenin ortamını aktif edeceğini soruyor. Önceden sessiz sedasız birini seçiyordu — genelde yanlış olanı, tabiî (inanın bana). Murphy yasası sanki özellikle burada çalışıyordu.

PowerShell Aktivasyon Sorunu

Şunu söyleyeyim, Windows tarafında iş gören bir düzeltme bu. PowerShell’de execution policy kısıtlaması yüzünden .ps1 aktivasyon scriptleri bazen çalışmıyordu; eklenti şimdi aktivasyondan önce process-scoped bir execution policy ayarlıyor,. Sistem genelindeki ayara dokunmadan sadece o terminal oturumu için izin veriyor. Güzel detay, ama dur bir saniye — asıl farkı yeni başlayanlar hissediyor. CodeAct ile AI Agent’ları Hızlandırmak: %50 Daha Az Gecikme yazımızda bu konuya da değinmiştik.

Bunu 2023’te kendi başıma çözmüştüm aslında; PowerShell profilime Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass satırını eklemiştim. Fena değil, iş görüyordu, fakat yeni bir geliştirici için bu hata gerçekten kafa karıştırıcıydı. İyi ki bunu otomatik hâle getirmişler.

Türkiye’deki Ekipler İçin Pratik Değerlendirme

Şimdi asıl söylemek istediğim yere gelelim. Türkiye’deki yazılım ekiplerinde VS Code kullanımı son 3-4 yılda baya arttı, bunu sahada da net görüyorum; özellikle veri bilimi tarafında ve backend Python ekiplerinde neredeyse varsayılan hâle geldi, ama iş ortam yönetimine gelince işler biraz dağılıyor.

İşin garip tarafı şu: ekipler hâlâ “herkes kendi bildiği gibi yapsın” modunda ilerliyor. Birisi venv kullanıyor, diğeri conda, üçüncüsü poetry… Aynı projede. Bak şimdi, burada sorun araç değil; asıl mesele tutarlılık eksikliği,. Ekip büyüdükçe bu küçük farklar bir anda uğraştırıcı hâle geliyor.

Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.

Bu güncellemeyle birlikte benim önerim net: eğer küçük bir ekipseniz ya da startup’ta çalışıyorsanız, venv + uv kombinasyonuna geçin. uv zaten hızlı, bu eklenti de artık venv‘e öncelik veriyor, yanı fazladan manager yüküyle uğraşmıyorsunuz; tarama süresi de minimumda kalıyor, açık konuşayım baya iş görüyor. azure terraform azapi sağlayıcı nasıl kullanılır türkçe rehberi: Adım Adım yazımızda bu konuya da değinmiştik.

Büyük kurumsal yapılarda işe tablo biraz değişiyor. Mesela 50+ kişilik bir geliştirme ekibi varsa, monorepo yapısı kullanıyorsanız ya da Remote-SSH ile çalışıyorsanız, o zaman python-envs.workspaceSearchPaths ayarını genelde özelleştirin; varsayılan değer çoğu senaryoda idare eder. Derin dizin yapılarında eksik kalabiliyor, sonra da “neden ortamı bulmadı?” diye bakıp duruyorsunuz. Daha fazla bilgi için Kubernetes v1.36 User Namespaces GA: Root Artık Gerçek Root Değil yazımıza bakabilirsiniz.

Kısa bir not düşeyim buraya.

Senaryo	Önerilen Ortam Aracı	Workspace Search Ayarı	Beklenen Başlangıç Süresi
Küçük ekip / startup	venv + uv	Varsayılan yeterli	1-3 saniye
Veri bilimi ekibi	conda	Varsayılan yeterli	3-5 saniye
Monorepo / Remote-SSH	venv veya poetry	Özelleştirilmeli	3-8 saniye (önceden 30+)
Container-based geliştirme	venv (devcontainer içinde)	Varsayılan yeterli	2-4 saniye

Garip gelecek ama, Evet. Burada can alıcı nokta hız değil sadece; ekip içindeki davranışın sadeleşmesi de önemli. Microsoft ve OpenAI Ortaklığının Yeni Dönemi: Ne Değişiyor? yazımızda bu konuya da değinmiştik.

Açık konuşayım, Peki neden? Çünkü aynı proje içinde üç farklı ortam yaklaşımı olunca, destek vermek de kodu taşımak da gereksiz yere uzuyor. Hani bazen küçük bir ayar yüzünden yarım gün gidiyor ya, işte tam o dertten bahsediyorum.

Neyse, çok dağıtmadan söyleyeyim: doğru araç seçimi kadar doğru varsayılanlar da fark yaratıyor. Sız ne dersiniz? Bu konuyla ilgili Copilot Student’ta GPT-5.3-Codex Kalktı: Ne Yapmalı? yazımıza da göz atmanızı tavsiye ederim.

Eksik Kalan Ne? Biraz da Eleştirelim

Her şey güllük gülistanlık mı? Değil. Birkaç şey hâlâ eksik, açık konuşayım.

İlk mesele uv desteği. Son bir yılda baya popüler öldü ama eklentideki entegrasyon, conda ya da venv kadar derin değil; mesela geçen ay kendi projemde uv ile kurulmuş ortamı otomatik bulamadı, ben de interpreter path’i elle gösterdim. Kağıt üstünde var, pratikte işe biraz daha pişmesi gerekiyor.

İkincisi, multi-root workspace tarafı hâlâ biraz karışık. Terminal açarken hangi projeyi seçmek istediğinizi soruyor, tamam güzel, ama ortam listesi yine tek yerde toplanıyor; 5-6 proje olan bir workspace’te hangi ortamın kime ait olduğunu anlamak, şey, düşündüğünüzden zor olabiliyor.

Şahsen, Üçüncü konu da benim kişisel can sıkıntım: hâlâ bir “ortam sağlık kontrolü” yok. Yanı “bu ortamdaki paketler requirements.txt ile uyumlu mu?” diye basit bir bakış atamıyoruz; bunu hâlâ elle yapıyoruz ya da pip check ile dönüyoruz. Belki sonraki sürümlerde gelir, kim bilir.

Azure üzerinde çalışan ekipler için bu tarz geliştirme ortamı iyileştirmeleri gerçekten iş görüyor. Eğer CI/CD tarafında da ufak ama etkili dokunuşlar arıyorsanız, Azure DevOps Git Policy Yönetimi: 10x Hız Kazanmanın Yolu yazıma da göz atın derim.

İlk Adım Olarak Ne Yapmalısınız?

Tamam, güncellemeyi beğendiniz diyelim. Peki şimdi ne olacak? Hani işin kritik kısmı var ya, asıl oraya geliyoruz.

VS Code’da Python Environments eklentisini güncelleyin (auto-update açıksa zaten kendi kendine gelmiş olabilir, ona da bakın).
settings.json‘ınızı açıp kontrol edin — eski python.venvPath ya da python.condaPath ayarları duruyorsa, yeni eklentiyle çakışabiliyor, o yüzden temizlemek iyi olur.
Eğer monorepo kullanıyorsanız veya dizin yapınız biraz derinse, python-envs.workspaceSearchPaths ayarını elle düzenleyin; yoksa eklenti bazen saçma sapan yerde arama yapıyor.
Remote-SSH ile bağlanıyorsanız, uzak taraftaki eklentinin de güncel olduğuna bakın — lokal taraf yeni sürümde kalır, remote taraf eskiyse insan boşuna uğraşıyor.
PowerShell kullanıyorsanız ve daha önce aktivasyon derdi yaşadıysanız, profil dosyasına eklenmiş eski execution policy satırlarını kaldırabilirsiniz. Evet, çoğu zaman artık gerekmiyor.

Bak şimdi, Konteyner tabanlı geliştirme yapıyorsanız, azure container apps türkçe başlangıç rehberi: Adım Adım Kurulum yazısı da işinize yarayabilir. Bir göz atın derim.

Geliştirici deneyimi sadece kod yazma hızına bakılarak ölçülmüyor. IDE’nın sizi ne kadar az beklettiği, ne kadar az ters köşe yaptığı da en az onun kadar önemli. Bu güncelleme tam da oraya dokunuyor.

💡 Bilgi: Python Environments eklentisi, eski “Python” eklentisindeki ortam yönetimi özelliklerinin ayrıştırılmış ve geliştirilmiş hali. Eğer hâlâ eski eklentiyi kullanıyorsanız, geçiş yapmanız önerilir — yeni eklenti hem daha hafif hem de daha hızlı.

Sıkça Sorulan Sorular

Python Environments eklentisi eski Python eklentisinin yerini mi alıyor?

Şunu fark ettim: Tam olarak değil, yanı ortam yönetimi kısmını devraldı. Linting, debugging gibi şeyler hâlâ ana Python eklentisinde yaşıyor. İkisi birlikte çalışıyor aslında. Ortam keşfi ve interpreter seçimi artık Python Environments tarafından yönetiliyor.

Remote-SSH üzerinde başlangıç hızı gerçekten iyileşti mi?

Evet! En çok da workspace tarama deseninin daraltılmasıyla epey fark yarattı. Büyük projelerde mesela 30+ saniyeden 3-8 saniyeye düşen senaryolar var. Bence bu oldukça ciddi bir iyileşme — tabiî her şey proje yapınıza ve ağ hızınıza bağlı, mucize beklemeyin. Ama fark büyük ihtimalle hissedilir.

Şimdi gelelim işin can alıcı noktasına.

uv ile oluşturulmuş ortamları otomatik buluyor mu?

Büyük ölçüde evet. uv’nın oluşturduğu .venv klasörünü tanıyor, ama açıkçası tam entegrasyon henüz tam anlamıyla olgunlaşmadı. Bazı edge case’lerde manuel path gösterimi gerekebiliyor. Gelecek güncellemelerde daha iyi olmasını bekliyorum.

PowerShell execution policy sorunu tamamen çözüldü mü?

Artık process-scoped bir policy ayarlıyor, yanı sistem genelindeki ayarınıza dokunmuyor — bu çoğu durumda yeterli oluyor. Ama hani şirket group policy’siyle PowerShell tamamen kilitlenmişse, o durumda IT ekibinizle konuşmaktan başka çare yok.

Conda ve venv ortamlarını aynı projede kullanabilir mıyım?

Neyse, şunu fark ettim: Teknik olarak kullanabilirsiniz, ama tecrübeme göre bunu önermiyorum. Karışıklığa yol açıyor ve eklenti de bazen hangisini önceliklendireceği konusunda kararsız kalabiliyor. Bir proje için tek bir ortam aracı seçin ve ona sadık kalın, çok daha rahat edersiniz.

Kaynaklar ve İleri Okuma

Python Environments Extension for VS Code — April 2026 Release (Resmî Blog Yazısı)

VS Code Python Extension — Visual Studio Marketplace

Python Environments Extension — GitHub Repository

İçeriği paylaş:

Aşkın KILIÇYazar

20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102