zetuptoolz delenda est #1582
Labels
No labels
c/code
c/code-dirnodes
c/code-encoding
c/code-frontend
c/code-frontend-cli
c/code-frontend-ftp-sftp
c/code-frontend-magic-folder
c/code-frontend-web
c/code-mutable
c/code-network
c/code-nodeadmin
c/code-peerselection
c/code-storage
c/contrib
c/dev-infrastructure
c/docs
c/operational
c/packaging
c/unknown
c/website
kw:2pc
kw:410
kw:9p
kw:ActivePerl
kw:AttributeError
kw:DataUnavailable
kw:DeadReferenceError
kw:DoS
kw:FileZilla
kw:GetLastError
kw:IFinishableConsumer
kw:K
kw:LeastAuthority
kw:Makefile
kw:RIStorageServer
kw:StringIO
kw:UncoordinatedWriteError
kw:about
kw:access
kw:access-control
kw:accessibility
kw:accounting
kw:accounting-crawler
kw:add-only
kw:aes
kw:aesthetics
kw:alias
kw:aliases
kw:aliens
kw:allmydata
kw:amazon
kw:ambient
kw:annotations
kw:anonymity
kw:anonymous
kw:anti-censorship
kw:api_auth_token
kw:appearance
kw:appname
kw:apport
kw:archive
kw:archlinux
kw:argparse
kw:arm
kw:assertion
kw:attachment
kw:auth
kw:authentication
kw:automation
kw:avahi
kw:availability
kw:aws
kw:azure
kw:backend
kw:backoff
kw:backup
kw:backupdb
kw:backward-compatibility
kw:bandwidth
kw:basedir
kw:bayes
kw:bbfreeze
kw:beta
kw:binaries
kw:binutils
kw:bitcoin
kw:bitrot
kw:blacklist
kw:blocker
kw:blocks-cloud-deployment
kw:blocks-cloud-merge
kw:blocks-magic-folder-merge
kw:blocks-merge
kw:blocks-raic
kw:blocks-release
kw:blog
kw:bom
kw:bonjour
kw:branch
kw:branding
kw:breadcrumbs
kw:brians-opinion-needed
kw:browser
kw:bsd
kw:build
kw:build-helpers
kw:buildbot
kw:builders
kw:buildslave
kw:buildslaves
kw:cache
kw:cap
kw:capleak
kw:captcha
kw:cast
kw:centos
kw:cffi
kw:chacha
kw:charset
kw:check
kw:checker
kw:chroot
kw:ci
kw:clean
kw:cleanup
kw:cli
kw:cloud
kw:cloud-backend
kw:cmdline
kw:code
kw:code-checks
kw:coding-standards
kw:coding-tools
kw:coding_tools
kw:collection
kw:compatibility
kw:completion
kw:compression
kw:confidentiality
kw:config
kw:configuration
kw:configuration.txt
kw:conflict
kw:connection
kw:connectivity
kw:consistency
kw:content
kw:control
kw:control.furl
kw:convergence
kw:coordination
kw:copyright
kw:corruption
kw:cors
kw:cost
kw:coverage
kw:coveralls
kw:coveralls.io
kw:cpu-watcher
kw:cpyext
kw:crash
kw:crawler
kw:crawlers
kw:create-container
kw:cruft
kw:crypto
kw:cryptography
kw:cryptography-lib
kw:cryptopp
kw:csp
kw:curl
kw:cutoff-date
kw:cycle
kw:cygwin
kw:d3
kw:daemon
kw:darcs
kw:darcsver
kw:database
kw:dataloss
kw:db
kw:dead-code
kw:deb
kw:debian
kw:debug
kw:deep-check
kw:defaults
kw:deferred
kw:delete
kw:deletion
kw:denial-of-service
kw:dependency
kw:deployment
kw:deprecation
kw:desert-island
kw:desert-island-build
kw:design
kw:design-review-needed
kw:detection
kw:dev-infrastructure
kw:devpay
kw:directory
kw:directory-page
kw:dirnode
kw:dirnodes
kw:disconnect
kw:discovery
kw:disk
kw:disk-backend
kw:distribute
kw:distutils
kw:dns
kw:do_http
kw:doc-needed
kw:docker
kw:docs
kw:docs-needed
kw:dokan
kw:dos
kw:download
kw:downloader
kw:dragonfly
kw:drop-upload
kw:duplicity
kw:dusty
kw:earth-dragon
kw:easy
kw:ec2
kw:ecdsa
kw:ed25519
kw:egg-needed
kw:eggs
kw:eliot
kw:email
kw:empty
kw:encoding
kw:endpoint
kw:enterprise
kw:enum34
kw:environment
kw:erasure
kw:erasure-coding
kw:error
kw:escaping
kw:etag
kw:etch
kw:evangelism
kw:eventual
kw:example
kw:excess-authority
kw:exec
kw:exocet
kw:expiration
kw:extensibility
kw:extension
kw:failure
kw:fedora
kw:ffp
kw:fhs
kw:figleaf
kw:file
kw:file-descriptor
kw:filename
kw:filesystem
kw:fileutil
kw:fips
kw:firewall
kw:first
kw:floatingpoint
kw:flog
kw:foolscap
kw:forward-compatibility
kw:forward-secrecy
kw:forwarding
kw:free
kw:freebsd
kw:frontend
kw:fsevents
kw:ftp
kw:ftpd
kw:full
kw:furl
kw:fuse
kw:garbage
kw:garbage-collection
kw:gateway
kw:gatherer
kw:gc
kw:gcc
kw:gentoo
kw:get
kw:git
kw:git-annex
kw:github
kw:glacier
kw:globalcaps
kw:glossary
kw:google-cloud-storage
kw:google-drive-backend
kw:gossip
kw:governance
kw:grid
kw:grid-manager
kw:gridid
kw:gridsync
kw:grsec
kw:gsoc
kw:gvfs
kw:hackfest
kw:hacktahoe
kw:hang
kw:hardlink
kw:heartbleed
kw:heisenbug
kw:help
kw:helper
kw:hint
kw:hooks
kw:how
kw:how-to
kw:howto
kw:hp
kw:hp-cloud
kw:html
kw:http
kw:https
kw:i18n
kw:i2p
kw:i2p-collab
kw:illustration
kw:image
kw:immutable
kw:impressions
kw:incentives
kw:incident
kw:init
kw:inlineCallbacks
kw:inotify
kw:install
kw:installer
kw:integration
kw:integration-test
kw:integrity
kw:interactive
kw:interface
kw:interfaces
kw:interoperability
kw:interstellar-exploration
kw:introducer
kw:introduction
kw:iphone
kw:ipkg
kw:iputil
kw:ipv6
kw:irc
kw:jail
kw:javascript
kw:joke
kw:jquery
kw:json
kw:jsui
kw:junk
kw:key-value-store
kw:kfreebsd
kw:known-issue
kw:konqueror
kw:kpreid
kw:kvm
kw:l10n
kw:lae
kw:large
kw:latency
kw:leak
kw:leasedb
kw:leases
kw:libgmp
kw:license
kw:licenss
kw:linecount
kw:link
kw:linux
kw:lit
kw:localhost
kw:location
kw:locking
kw:logging
kw:logo
kw:loopback
kw:lucid
kw:mac
kw:macintosh
kw:magic-folder
kw:manhole
kw:manifest
kw:manual-test-needed
kw:map
kw:mapupdate
kw:max_space
kw:mdmf
kw:memcheck
kw:memory
kw:memory-leak
kw:mesh
kw:metadata
kw:meter
kw:migration
kw:mime
kw:mingw
kw:minimal
kw:misc
kw:miscapture
kw:mlp
kw:mock
kw:more-info-needed
kw:mountain-lion
kw:move
kw:multi-users
kw:multiple
kw:multiuser-gateway
kw:munin
kw:music
kw:mutability
kw:mutable
kw:mystery
kw:names
kw:naming
kw:nas
kw:navigation
kw:needs-review
kw:needs-spawn
kw:netbsd
kw:network
kw:nevow
kw:new-user
kw:newcaps
kw:news
kw:news-done
kw:news-needed
kw:newsletter
kw:newurls
kw:nfc
kw:nginx
kw:nixos
kw:no-clobber
kw:node
kw:node-url
kw:notification
kw:notifyOnDisconnect
kw:nsa310
kw:nsa320
kw:nsa325
kw:numpy
kw:objects
kw:old
kw:openbsd
kw:openitp-packaging
kw:openssl
kw:openstack
kw:opensuse
kw:operation-helpers
kw:operational
kw:operations
kw:ophandle
kw:ophandles
kw:ops
kw:optimization
kw:optional
kw:options
kw:organization
kw:os
kw:os.abort
kw:ostrom
kw:osx
kw:osxfuse
kw:otf-magic-folder-objective1
kw:otf-magic-folder-objective2
kw:otf-magic-folder-objective3
kw:otf-magic-folder-objective4
kw:otf-magic-folder-objective5
kw:otf-magic-folder-objective6
kw:p2p
kw:packaging
kw:partial
kw:password
kw:path
kw:paths
kw:pause
kw:peer-selection
kw:performance
kw:permalink
kw:permissions
kw:persistence
kw:phone
kw:pickle
kw:pip
kw:pipermail
kw:pkg_resources
kw:placement
kw:planning
kw:policy
kw:port
kw:portability
kw:portal
kw:posthook
kw:pratchett
kw:preformance
kw:preservation
kw:privacy
kw:process
kw:profile
kw:profiling
kw:progress
kw:proxy
kw:publish
kw:pyOpenSSL
kw:pyasn1
kw:pycparser
kw:pycrypto
kw:pycrypto-lib
kw:pycryptopp
kw:pyfilesystem
kw:pyflakes
kw:pylint
kw:pypi
kw:pypy
kw:pysqlite
kw:python
kw:python3
kw:pythonpath
kw:pyutil
kw:pywin32
kw:quickstart
kw:quiet
kw:quotas
kw:quoting
kw:raic
kw:rainhill
kw:random
kw:random-access
kw:range
kw:raspberry-pi
kw:reactor
kw:readonly
kw:rebalancing
kw:recovery
kw:recursive
kw:redhat
kw:redirect
kw:redressing
kw:refactor
kw:referer
kw:referrer
kw:regression
kw:rekey
kw:relay
kw:release
kw:release-blocker
kw:reliability
kw:relnotes
kw:remote
kw:removable
kw:removable-disk
kw:rename
kw:renew
kw:repair
kw:replace
kw:report
kw:repository
kw:research
kw:reserved_space
kw:response-needed
kw:response-time
kw:restore
kw:retrieve
kw:retry
kw:review
kw:review-needed
kw:reviewed
kw:revocation
kw:roadmap
kw:rollback
kw:rpm
kw:rsa
kw:rss
kw:rst
kw:rsync
kw:rusty
kw:s3
kw:s3-backend
kw:s3-frontend
kw:s4
kw:same-origin
kw:sandbox
kw:scalability
kw:scaling
kw:scheduling
kw:schema
kw:scheme
kw:scp
kw:scripts
kw:sdist
kw:sdmf
kw:security
kw:self-contained
kw:server
kw:servermap
kw:servers-of-happiness
kw:service
kw:setup
kw:setup.py
kw:setup_requires
kw:setuptools
kw:setuptools_darcs
kw:sftp
kw:shared
kw:shareset
kw:shell
kw:signals
kw:simultaneous
kw:six
kw:size
kw:slackware
kw:slashes
kw:smb
kw:sneakernet
kw:snowleopard
kw:socket
kw:solaris
kw:space
kw:space-efficiency
kw:spam
kw:spec
kw:speed
kw:sqlite
kw:ssh
kw:ssh-keygen
kw:sshfs
kw:ssl
kw:stability
kw:standards
kw:start
kw:startup
kw:static
kw:static-analysis
kw:statistics
kw:stats
kw:stats_gatherer
kw:status
kw:stdeb
kw:storage
kw:streaming
kw:strports
kw:style
kw:stylesheet
kw:subprocess
kw:sumo
kw:survey
kw:svg
kw:symlink
kw:synchronous
kw:tac
kw:tahoe-*
kw:tahoe-add-alias
kw:tahoe-admin
kw:tahoe-archive
kw:tahoe-backup
kw:tahoe-check
kw:tahoe-cp
kw:tahoe-create-alias
kw:tahoe-create-introducer
kw:tahoe-debug
kw:tahoe-deep-check
kw:tahoe-deepcheck
kw:tahoe-lafs-trac-stream
kw:tahoe-list-aliases
kw:tahoe-ls
kw:tahoe-magic-folder
kw:tahoe-manifest
kw:tahoe-mkdir
kw:tahoe-mount
kw:tahoe-mv
kw:tahoe-put
kw:tahoe-restart
kw:tahoe-rm
kw:tahoe-run
kw:tahoe-start
kw:tahoe-stats
kw:tahoe-unlink
kw:tahoe-webopen
kw:tahoe.css
kw:tahoe_files
kw:tahoewapi
kw:tarball
kw:tarballs
kw:tempfile
kw:templates
kw:terminology
kw:test
kw:test-and-set
kw:test-from-egg
kw:test-needed
kw:testgrid
kw:testing
kw:tests
kw:throttling
kw:ticket999-s3-backend
kw:tiddly
kw:time
kw:timeout
kw:timing
kw:to
kw:to-be-closed-on-2011-08-01
kw:tor
kw:tor-protocol
kw:torsocks
kw:tox
kw:trac
kw:transparency
kw:travis
kw:travis-ci
kw:trial
kw:trickle
kw:trivial
kw:truckee
kw:tub
kw:tub.location
kw:twine
kw:twistd
kw:twistd.log
kw:twisted
kw:twisted-14
kw:twisted-trial
kw:twitter
kw:twn
kw:txaws
kw:type
kw:typeerror
kw:ubuntu
kw:ucwe
kw:ueb
kw:ui
kw:unclean
kw:uncoordinated-writes
kw:undeletable
kw:unfinished-business
kw:unhandled-error
kw:unhappy
kw:unicode
kw:unit
kw:unix
kw:unlink
kw:update
kw:upgrade
kw:upload
kw:upload-helper
kw:uri
kw:url
kw:usability
kw:use-case
kw:utf-8
kw:util
kw:uwsgi
kw:ux
kw:validation
kw:variables
kw:vdrive
kw:verify
kw:verlib
kw:version
kw:versioning
kw:versions
kw:video
kw:virtualbox
kw:virtualenv
kw:vista
kw:visualization
kw:visualizer
kw:vm
kw:volunteergrid2
kw:volunteers
kw:vpn
kw:wapi
kw:warners-opinion-needed
kw:warning
kw:weapi
kw:web
kw:web.port
kw:webapi
kw:webdav
kw:webdrive
kw:webport
kw:websec
kw:website
kw:websocket
kw:welcome
kw:welcome-page
kw:welcomepage
kw:wiki
kw:win32
kw:win64
kw:windows
kw:windows-related
kw:winscp
kw:workaround
kw:world-domination
kw:wrapper
kw:write-enabler
kw:wui
kw:x86
kw:x86-64
kw:xhtml
kw:xml
kw:xss
kw:zbase32
kw:zetuptoolz
kw:zfec
kw:zookos-opinion-needed
kw:zope
kw:zope.interface
p/blocker
p/critical
p/major
p/minor
p/normal
p/supercritical
p/trivial
r/cannot reproduce
r/duplicate
r/fixed
r/invalid
r/somebody else's problem
r/was already fixed
r/wontfix
r/worksforme
t/defect
t/enhancement
t/task
v/0.2.0
v/0.3.0
v/0.4.0
v/0.5.0
v/0.5.1
v/0.6.0
v/0.6.1
v/0.7.0
v/0.8.0
v/0.9.0
v/1.0.0
v/1.1.0
v/1.10.0
v/1.10.1
v/1.10.2
v/1.10a2
v/1.11.0
v/1.12.0
v/1.12.1
v/1.13.0
v/1.14.0
v/1.15.0
v/1.15.1
v/1.2.0
v/1.3.0
v/1.4.1
v/1.5.0
v/1.6.0
v/1.6.1
v/1.7.0
v/1.7.1
v/1.7β
v/1.8.0
v/1.8.1
v/1.8.2
v/1.8.3
v/1.8β
v/1.9.0
v/1.9.0-s3branch
v/1.9.0a1
v/1.9.0a2
v/1.9.0b1
v/1.9.1
v/1.9.2
v/1.9.2a1
v/cloud-branch
v/unknown
No milestone
No project
No assignees
5 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: tahoe-lafs/trac#1582
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
We need to stop using setuptools, for the following reasons:
Dealing with the effects of setuptools' problems on Tahoe-LAFS has inconvenienced users on many occasions and wasted a huge amount of core developer time. This ticket is to find, or to design and implement, an alternative.
See also /tahoe-lafs/trac/issues/27395#comment:-1 .
I feel like this isn't as urgent as most bugs marked "Priority: Critical". If you disagree, then I apologize for overwriting the priority setting you left. Note that as the months and years have gone by, various other tools have been developed or improved; tools that we might be able to use, such as "Wheel" by Daniel Tolth, and "Paver". There are probably a few others that I haven't even heard of. Also pip and virtualenv have been ubiquitous and popular.
Major because of the sheer amount of pain setuptools has caused us. (pip doesn't solve most of those problems because it's just a frontend to setuptools, and the issues with setuptools are not
primarily inlimited to itseasy_install
frontend.)peep is another tool that intends to address this problem. I couldn't get it to work on Tahoe; it downloaded the required sdists and then blew up with an exception from pip, which it depends on:
If I understand correctly, pip by itself does not help you at all in verifying the integrity of dependencies; at most it will download the package you're directly installing over https.
Replying to daira:
More about what pip actually does: https://github.com/TheTorProject/ooni-backend/pull/1#discussion-diff-4084881.
I despair of Python package installation tools getting any better unless one is written COMPLETELY FROM SCRATCH by someone who knows what they're doing.
I don't believe the packaging tools need rewritten from scratch to enable secure install.
pip will verify the integrity of the downloads if it has that information available. Currently it is using md5 to do that (although that's not pip's doing, it supports md5, sha1, and sha2). At the urging of some members of ooni I am preparing to "once more into the breach" to fight for a better hash on PyPI.
The behavior described in the ooni pull request about scraping is mostly correct. However on July 1st I removed most link scraping from PyPI and the imminent pip 1.4 release makes the insecure external scraping opt-out on the installer side, and 1.5 will make it opt-in.
There is currently nothing like peep where you can bake a hash into a requirements.txt and verify against that, but it is something I want to enable. (As a side note, the above probably failed, because I don't believe a requires.txt is going to have the same format as requirements.txt).
Beyond that can you provide more information on:
The other issues I believe are either fixed, or are becoming fixed.
dstufft: thank you for your comment! In my opinion, an important thing going on here is just that Daira has strong negative emotions about setuptools. I don't want to push her to keep working on debugging and tweaking setuptools-based tools. On the other hand, I don't want to rip out all the setuptools stuff and replace it, either! So the ideal path forward in my opinion is either that we all pretend to ignore the problem and work on other things, or that someone other than Daira takes responsibility for diagnosing and fixing packaging-related issues.
Also Brian is pretty much in the same boat as Daira in hating and resenting a lot of setuptools-related issues. (In my opinion. Not to put words in their mouths!)
Actually I'm not too keen on spending my time debugging that stuff either. ;-)
So, if someone (like dstufft!) wants to help us with our packaging, that would be greatly appreciated.
zooko: I have no problem with helping to debug things, although I'm unlikely to have a ton of time to submit actual patches though D:
I'm more than willing to help debug things though if people have specific problems or tracebacks/logs that they can point me towards to see what's going on :) I joined the #tahoe-lafs channel and folks can ping me there for more immediate help if needed.
I know setuptools isn't the greatest thing in the world, and there is work being done to phase it out eventually :)
Replying to dstufft:
#1258 and #1287, for example.
Also #1450 and #1451.
And /tahoe-lafs/trac/issues/27190#comment:387588 .
So those tickets are all variations on the same theme, and that theme is multi version installs are terrible and setuptools does them by default. That's why pip disabled them. You could probably override setup.py build|install|egg_info|develop etc to use pip instead of easy_install, or just tell everyone to use pip ;)
It would be very good for this ticket description to link to as many specific issues as possible in the setuptools, pip, and https://github.com/pypa/packaging-problems issue trackers, so that the problems can be run down in the place most obviously responsible for them. As it stands, most of this is accurate, but nebulous, griping about an old version of setuptools that Tahoe is stuck on, rather than an accurate framing of the state of the art.
When this ticket was filed, the setuptools team was leaving a period of being insular, unresponsive, and basically user-hostile. In the interim, setuptools has vastly accelerated its release cadence, increased its responsiveness to user bugs, and developed an ecosystem of tools and practices to obviate many of the issues discussed here.
The situation is still pretty bad in some corners, but it's vastly better than it once was, and most importantly, it is at least now worthwhile to go through the effort of filing specific issues because they do, in fact, get addressed eventually.
I would very much like to switch to using pip with a virtualenv rather than zetuptoolz with the hack to build dependencies under the
support/
directory. However we're at completely the wrong stage in Tahoe's release cycle to work on that right now; it will have to wait until 1.11 at least.Sure; no rush. I am just trying to get my head around why exactly zetuptoolz exists, and which of these issues still exist vs. which don't. For example - would switching to a virtualenv fully address the things that motivated this ticket?
BTW there is a lot of very precise detail in the linked tickets about exactly what goes wrong whenever there are multiple packages installed under the same directory. As far as I know, none of that has been fixed.
Discussion of how to use pip and virtualenv should be on ticket #2077.
Review needed for https://github.com/tahoe-lafs/tahoe-lafs/pull/213!
I think we also want to enforce a minimum version of setuptools and/or use virtualenv automatically where available, but this branch can act as a base for that.
Glyph mentioned that Tahoe pins pyOpenSSL to 0.13 because of various setuptools reasons. Since I want to phase out support for non-Cryptography-using pyOpenSSL, I thought I'd post a comment here saying that using anything below 0.15.1 will be deprecated soon, and I don't want Tahoe to be left in the dark. :)
Tahoe doesn't actually pin pyOpenSSL to 0.13. It will happily use >= 0.14 if such a version is already installed (i.e. it reports its version as >= 0.14 when imported), but it will only request to build >= 0.13, <= 0.13.1 otherwise.
Also, this is not for setuptools reasons, at least not directly. It is because our experience was that the dependency on cffi was causing too many build failures.
Replying to daira:
I vaguely remember discussing this (it is kind of hard to find history in all these different tickets) but I don't see it mentioned here, and the situation has changed a lot since 2013, so, here goes:
Right now, Cryptography distributes wheels for OS X and Windows, which bundle OpenSSL and seem to install very reliably; I am fielding far fewer complaints about Twisted not installing due to build errors on those platforms, and it was a real headache when pyOpenSSL first moved.
This effort is also underway - https://github.com/manylinux/manylinux - to allow wheels to be provided that will robustly work across any possible reasonable linux distribution.
Does this change the situation at all for Tahoe?
Separately you may be interested in https://github.com/manylinux/auditwheel for your own purposes if Tahoe is producing its own build artifacts.
I'm quite happy to accept that the installation situation has improved. Does it still require manual installation of libffi, or is that now statically linked with the wheel? (Split the answer by platform and/or distribution if necessary.)
setuptools delenda estto zetuptoolz delenda estReplying to daira:
I believe the wheels statically link libffi on all platforms. It certainly must on Windows, because I've done
pip install cryptography
there, and it works, and I definitely never installed libffi on that platform. On OS X, there is guaranteed to be a system version of libffi, so it's less important there.On Linux I would presume static libffi would be a must.
On Windows 7 using the 1582.setuptools-delenda-est.1 branch:
It looks like the enthusiastically-long pycryptopp version string is causing a
shutil.copy()
call to exceed the windows maximum pathname length. It's exacerbated by the string being used twice (in some sort of$PKGVER.tmp/../$PKGVER
syntax). It's possible that this could be fixed in setuptools, but it might also mean that zooko has to give up his beloved versioning scheme.We don't yet know what's going on with the pyasn1 error.
At today's meeting we decided to (at least provisionally) include this in the next release. It fixes #2728, which is probably a blocker, and should help reduce the need for a compiler, which has always been a problem on windows. It'd also close about half our outstanding "packaging" tickets.
There are other steps necessary if we really do include this:
pip install --editable .
pip install allmydata-tahoe
and get the version from PyPIallmydata-tahoe
totahoe-lafs
(#2011, but not #1950)I'll assemble a branch with proposed docs changes, and will look into the buildbot changes.
Packaging tickets that would probably be closed if we land this: #709 #717 #799 #1270 #1403 #1450 #1451 #1504 #1896 #2044 #2221 #2728 #1168 #1753 #2021 #2077 #2210 #2255 #2283 #2286 #2306 #2317 #2468 #2473 #2474 #657
Tickets that would not be closed, but would become a lot easier to resolve: #1220 #1244 #1343 #2055 #2475 #1342 #142
Do you have any 32-bit Windows users? I notice that Twisted is presently only shipping a wheel for Windows, and only for 64-bit. We could probably do a bit better here and ship 32-bit Windows wheels and OS X wheels as well.
Also: it's not causing any problems right now, but you'll probably be pleased to know that in Twisted trunk right now, we've removed PyCrypto as a dependency, and are now doing everything in
conch
withcryptography
. We still need to get rid ofpyOpenSSL
but at least we only have one backend now. (Once we get rid of the dependency on OpenSSL's TLS specifics, which is a goal that's in sight now, we might even be able to have acryptography
backend that pulls from pycryptopp exclusively, modulo just a little dependency-mangling magic on their side...)The 1582.setuptools-delenda-est.1 branch is now looking in much better shape on Windows. In a virtualenv:
works for me and passes all tests.
As I suspected, Unicode command-line support on Windows is broken on this branch. It works fine if you use
python tahoe-script.py ...
though; the problem is just thetahoe.exe
executable generated by setuptools not passing through arguments correctly (see #565 and #1074).daira, I looked for a bug on the setuptools tracker ( https://bitbucket.org/pypa/setuptools/issues?status=new&status=open ) and could not find unicode command-line arguments as a bug there. Can you file one?
BTW, for those visiting this ticket in the future, the original intent was to stop using setuptools, i.e. go back to
distutils
. This was borne out of frustration with the bad-old-days when setuptools was not being maintained, forks likedistribute
were rampant, andvirtualenv
was not yet a thing. Later, setuptools improved for the better, andvirtualenv
provided a well-supported way of doing the funky custom thing we'd built in Tahoe. So some time around 2014 or 2015, we changed our minds, embraced the new setuptools, and this ticket was changed to be about stopping our use of zetuptoolz (Tahoe's embedded fork of setuptools, by this point horribly horribly ancient).Thanks for the update, warner. Posterity thanks you :). Perhaps we should update the ticket description as well, to clarify the present intention?
Replying to warner:
That's the wrong way to describe this problem. The facts are:
setuptools uses the short-paths Windows API instead of the long-paths Windows API. That's the root of the problem, and it is probably easy to fix (you just prepend
\\
or something like that to the paths, and then Windows handles long paths).Because of this bug, the build will fail whenever the base directory that you're starting in, plus 2 times the name of your package, exceeds 256 bytes (I think).
Therefore, the build will always fail if the base directory that you're starting in has too long of a pathname, and it will always succeed (at least with all current package names), if the base directory you're in has sufficiently short of a pathname.
Therefore, reducing the size of pycryptopp's package name would be a kludge that would only prevent the error in some of the cases. Fixes that can fix the problem in all of the cases are:
Build in a directory with a short name, e.g. "C:/build". That is a workaround that anybody can do without changing the code.
Fix setuptools to use the correct Windows API, by prepending
\\
or whatever it is to the pathnames before callingshutil.copy()
.I'm not going to change the pycryptopp versioning scheme.
Here's a way to test whether I'm right about what I said in comment:38:/tahoe-lafs/trac/issues/27526:
Make a directory named 'C:/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'.
chdir into it.
Try to build any package at all.
If I'm right, the build will fail, regardless of which package you try to build, because of this bug in setuptools. This is not pycryptopp's problem.
If I'm right, then the workaround, whether you're building pycryptopp or any other package is "chdir into a directory with a shorter and shorter name until the build works".
Moving the setuptools-vs-pycryptopp issue to #2739 .
In d8549a2/trunk:
In 389efdf/trunk:
In aa8a5be/trunk:
In fe360ee4/trunk:
Reviewed https://github.com/warner/tahoe-lafs/commit/01d7f11e1ff88c9cd489287fc77e1fe64c5dcb5d
Zetuptoolz is no more!!11!1 \o/
Replying to daira:
🎉
👍
Thank you to everyone who participated in this issue, especially daira, who I know suffered greatly on the torturous path to this eventual, glorious resolution :-).
Milestone renamed