首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

使用新版本号重新上传已删除的PyPi项目

,可以按照以下步骤进行操作:

  1. 确认项目已经被删除:在PyPi官网或使用命令行工具(如pip)搜索该项目,确保项目已被删除。
  2. 更新项目代码:在本地开发环境中,将项目代码更新到新的版本号。可以通过修改项目的setup.py或者pyproject.toml文件中的版本号来实现。
  3. 构建项目包:使用命令行工具进入项目根目录,执行构建命令,将项目打包成可发布的格式。例如,使用setuptools工具可以执行以下命令:
代码语言:txt
复制
python setup.py sdist bdist_wheel

这将生成一个dist目录,其中包含了项目的打包文件。

  1. 注册PyPi账号:如果还没有PyPi账号,需要先注册一个账号。可以访问PyPi官网进行注册。
  2. 配置PyPi账号:在本地开发环境中,使用命令行工具执行以下命令,配置PyPi账号信息:
代码语言:txt
复制
pip install twine
twine config register

按照提示输入PyPi账号的用户名和密码。

  1. 上传项目包:使用twine工具上传项目包到PyPi服务器。执行以下命令:
代码语言:txt
复制
twine upload dist/*

这将会将dist目录下的所有文件上传到PyPi服务器。

  1. 验证上传结果:等待上传完成后,可以访问PyPi官网或使用命令行工具搜索项目,确认项目已经重新上传成功。

对于PyPi项目的重新上传,腾讯云提供了云原生应用平台TKE(Tencent Kubernetes Engine)来支持容器化部署和管理,可以将PyPi项目打包成容器镜像,并通过TKE进行部署和管理。详情请参考腾讯云TKE产品介绍:Tencent Kubernetes Engine (TKE)

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

分享2019年一种最新加快在苹果app store中上架的方法

预计近期苹果app应用上架的比較多,审核比較慢,如今一个app从提交到上架短则7。8天。长则2。3个星期。我在实际上线应用时,总结了一个简单有用的小技巧,能够加快上架时间,近期使用这样的方法后。我们基本上从提交应用到上架基本上控制在1个星期以内。 我们一般公布app流程是 1:app开发測试完毕2.0。 2:在iTunesconnect上添加新版本号更新2.0。 3:上传应用 4:应用进入 Waiting for review 状态 (2-9天) 5:应用进入In review 状态 (2-5天) 6:Processing for App store(10分钟) 7:Ready for sale (5分钟) ​8:For Sale ​app store审核中,主要费时的是4,5步骤。 在4步骤中,注意是我们说的排队时间,这个时间和这段时间上传的应用有数量有关。假设数量多,排队时间就比較长。假设数量少,排队时间就少。排队结束后,直接进入In Review状态,这个和应用本身设计有关。设计复杂的应用,审核时间略微长些,而且还有其它一些因素影响,假设被打回。会又一次进入4步的队列中,只是依据我的观察,应该有个专门被打回应用的队列,这个队列的优先级高于新上传的应用,所以,即使应用被打回。也会有较高优先级进入In Review,可是这个不是我们想看到的。 ​在整个上述过程中,花费的总时间我们没有办法控制,可是我们能够通过一些技巧,尽量做到,我们真实提交app时,我们的应用,处在4中队列的前面。所以。我们的做法是 ​1:开发应用的同一时候,在在iTunesconnect上添加新版本号更新2.0,并在当前版本号上简单升级版本号号,上传应用(这样做的目的:及时审核通过,用户也能够正常使用应用) 2:应用进入Waiting for review状态,同一时候开发測试新版本号应用(这个时间控制在5天左右) ​3:新版本号应用开发完毕。 ​4:从iTunesconnect上撤销用于排队版本号应用,上传新版本号app(一般3天左右) 5:应用进入In review 状态 (2-5天) 6:Processing for App store(10分钟) 7:Ready for sale (5分钟) ​8:For Sale ​​这个改变很easy,整个流程,由应用开发和苹果审核的串行过程改动为并行进行。从而加快app上线速度。 我们在一淘HD和手机一淘上均做了这些尝试,眼下验证OK,从提交应用到最后上线基本上控制在1周以内。 苹果的审核策略和流程一直在变化,我们要做的是在变化过程中寻找技巧,解决 app 应用上线最后一公里的问题。 下面是审核条例中,最近比较容易中招的条例,大家要注意

02

Python包管理整理:setuptoo

setuptool管理python相关的包 一、介绍 setuptool管理python相关的包的工具。这些包是zip格式发布,但是后缀一般都是.egg setuptool能解决python包的依赖关系 setuptool安装的包默认安装到/usr/local/lib/pythonX.X/site-packages/目录下 下载包默认到http://pypi.python.org/pypi下载 pypi为Python PackageIndex 二、安装setuptool工具 1、rhel/centos #yum -y install python-setuptools 2、freebsd #cd /usr/ports/devel/py-setuptools && make install clean 3、debian/ubuntu #sudo apt-get install python-setuptools 以上使用系统包管理系统安装后需要更新一下: # easy_install -U setuptools 4、通用方式 Download ez_setup.py , and then run: ez_setup.py -Zf http://peak.telecommunity.com/snapshots/ RuleDispatch #fetch http://peak.telecommunity.com/dist/ez_setup.py #python2.7 ez_setup.py python2.7指定版本号,以表示setuptool使用的python版本。未指定版本则使用默认,也表示默认安装的版本是最新版本。 这一约定方便,旧版本也可以继续使用 三、通过easy_install安装python包 (一)普通安装 #easy_install Babel (二)安装本地或网络文件系统中安装egg文件 #easy_install /net/src/eggs/py2.5.egg (三)指定包的下载路径安装 #easy_install http://trac-hacks.org/svn/iniadminplugin/0.11/ #easy_install http://trac-hacks.org/svn/accountmanagerplugin/trunk (四)从URL源码包安装 #easy_install  http://pypi.python.org/simple/asp/asp-0.1.2.4.tar.gz 条件asp-0.1.2.4.tar.gz包中的根目录中必须包括setup.py文件 (五)web上面搜索包,并自动安装 # easy_install -f http://pypi.python.org/simple/ asp (六)指定包的版本 # easy_install asp==0.1.2.1 如果指定的版本高于现有已安装的保本就是升级了 (七)升级包 升级到最新版本(不指定版本就会升级到最新版本 # easy_install -U asp 升级到指定版本 # easy_install -U asp==0.1.2.2 四、认证和配置文件 1、有些需要认证的python站点 easy_install -f http://uid@password@pypi.python.org/simple/packages 2、使用配置文件定义下载的站点和安装的目录 配置文件位置 当前目录/setup.cfg 或当前目录/.pydistutils.cfg 配置文件内容 find-links=http://pypi.python.org/simple/ #特定搜索包的URL allow=*.python.org #搜索的域名 install_dir=/src/lib/python    #这个目录需要在PYTHONPATH中 (sys.path) 更多帮助请看easy_install --help

01

一次发布有多个发行版,为什么Python发行包会这么难?

大多数编程语言包的生态系统都有两个层级(level):每个包都有一个或多个发布(release),每一次发布都可以用版本号(version)进行区分。Python 有第三个层级:每个发布都有一个或多个发行版(distribution),下载安装包时下载的实际文件就是这些发行版。在大多数语言中,这些文件都是发布的同义词,但是在Python 中「一个发布有多个发行版」是很重要的,因为使用最广泛的那些包,大多数发布实际上都有多个发行版。 为什么会这样呢?因为 Python 的特殊之处在于,它将 C 扩展(extension)视为该语言的一流特性,并试图隔离包的使用与编译 C 扩展。这意味着发行版需要包含编译 C 扩展后的得到的二进制代码,这种发行版(在其现代迭代中)被称为 binary wheels。 但是 C 扩展通常需要针对特定的 Python 版本和操作系统进行编译,因此需要使用多个 wheels 来实现普适性。此外,由于包的作者不能预测出所有的 Python 版本和操作系统,所以包含一个由包用户负责编译的源发行版也很重要。 尽管如此,用户们和大多数工具考虑的仍然是发布版本(release),而不是特定的发行版(distribution)。这可能会引起极大的不协调。例如,在一台机器上安装一个包可能需要几秒钟(因为存在匹配的二进制发行版),在另一台机器上可能需要几分钟甚至几个小时。 即使两台机器都能找到合适的二进制发行版来安装,它们的哈希值也不匹配,检测 MitM 攻击也会因此变得更加困难。因为 pip 这样的工具会自动找到在发布下「最合适」的发行版,当一个发行版与给定的系统兼容时会偏向于选择 binary wheel,如果有多个发行版与此系统兼容,则选择最合适的 binary wheel,如果不兼容,则返回到源发行版。 如果你已经安装了发布下的一个发行版之后,该发布又有一个新的发行版,这时就会出现很大的问题。而且这个问题几乎是不可避免的——因为 PyPI 一次只允许上传一个发行版,并会创建一包含这个发行版的新发布,所以在你上传最后一个发行版之前,一定会有人已经下载了第一个发行版。 在使用自动编译程序(buildbot)并行构建不同的发行版之后,这个问题变得更加常见,二进制发行版一般要比源发行版花费更长的时间。当一个包的作者在发布后的几个月或几年里,再去添加对新平台(或 python 的新版本)的支持时,这种情况就变得更糟糕了。当这种情况发生时,会有以下一些问题:

04
领券